Raise the maximum RSA key size back to 16384

This reverts part of
https://boringssl-review.googlesource.com/c/boringssl/+/80287. Despite
the original change landing in July, we encountered an application that
needs to support large RSA keys for now.

The motivation for dropping the limit was three-fold:

1. To avoid risk of hard-to-debug assembly crashes on Windows, because
   of a subtle requirement on stack access order.

2. To make it possible to comfortably allocate RSA temporaries on the
   stack.

3. To reduce the DoS exposure for calling applications, that often
   forget to check RSA key sizes when importing them.

The first of these turn out to be OK, but hanging by a thread. I've
added long comments to armv8-mont.pl to explain the preconditions.

A factor of 2 increase for the second is not great, but we can probably
still manage 2 KiB per temporary instead of 1 KiB.

The last of these is unfortunate as nothing changes the quadratic and
cubic scaling of RSA. We'll just need to go back to the increased risk
for now. We may, in the future, gate these oversized RSA keys on
application opt-in, and/or limit them to public keys.

Update-Note: Due to b/473446952, the DoS exposure of every application
that imports RSA keys had to be increased. Applications that import RSA
keys should constrain the size. It is particularly recommended that
applications *not* allow importing RSA-16384 private keys, as those are
512x slower than the standard RSA-2048 private keys that applications
will typically benchmark against.

Bug: 402677800
Bug: 473446952
Change-Id: Idb1b241a8bf307bac27d278b0e427b0474ffe77f
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/86928
Reviewed-by: Adam Langley <agl@google.com>
Commit-Queue: David Benjamin <davidben@google.com>