Fix beeu_mod_inverse_vartime on aarch64

https://boringssl-review.googlesource.com/c/boringssl/+/51805 added an
aarch64 version of the x86_64 beeu_mod_inverse_vartime. However, it did
not quite get the shift operations right for A and B.

If clz happened to return 64, the SHIFT256 macro bumps into aarch64 only
looking at the bottom 6 bits of the shift operand. That means, instead
of shifting the value, it jumbles the bits up a bit.

Fix this by clamping the shift amount to 63 bits at a time.

(There is nothing significant about how much we clamp the shift. The
file was already trying to clamp the shift to 64 bits, though
unsuccessfully. The x86_64 clamps it to 27 bits, because it needs to
compute the shift amount very differently. Though this does mean that
the Python pseudocode isn't right because it omits clmaping.)

This function is only used in P-256 ECDSA verification (not signing), on
aarch64 non-small builds. Because it still outputs *some* scalar, we do
not believe it (or really most mod inverse math bugs) can be
meaningfully used to forge ECDSA signatures:

Suppose an attacker could find some (msg, r, s) tuple that triggered
this bug and caused ECDSA verification to pass. ECDSA verification only
uses this function to compute inv(s) and afterwards never uses inv or s
again. The bug still outputs some valid scalar, so we have two cases:

Case 1: buggy_inv(s) != 0

Suppose the attacker instead passed (msg, r, correct_inv(buggy_inv(s))
to a correct ECDSA verifier. The correct ECDSA verifier would then
compute s_inv = buggy_inv(s) and then proceed the same as a verifier
with this bug. If that passes, that means the attacker must have been
able to break ECDSA without this bug anyway.

Case 2: buggy_inv(s) = 0

If this bug causes ECDSA verification to proceed with s_inv = 0, this
would bypass the s != 0 check at the start of verification. However, we
would then compute u1 = u2 = 0 and then 0 * pub + 0 * G = infinity.
Extracting the x-coordinate would then fail, so the signature would not
be accepted anyway.

Put another way, ECDSA signatures should simply have been (r, s^-1), not
(r, s). It's less work for the verifier, while both s and s^-1 are
equally easy for a signer to compute.

Change-Id: I91f44b57811f3eddd3f1973a7dc078c48e0329d7
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/93630
Presubmit-BoringSSL-Verified: boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com <boringssl-scoped@luci-project-accounts.iam.gserviceaccount.com>
Commit-Queue: Adam Langley <agl@google.com>
Auto-Submit: David Benjamin <davidben@google.com>
Reviewed-by: Adam Langley <agl@google.com>