bn_get_bits5 always reads two bytes, even when it doesn't need to. For some
sizes of |p|, this can result in reading just past the edge of the array.
Unroll the first iteration of the loop and avoid reading out of bounds.

Replace bn_get_bits5 altogether in C as it's not doing anything interesting.

Change-Id: Ibcc8cea7d9c644a2639445396455da47fe869a5c
Reviewed-on: https://boringssl-review.googlesource.com/1393
Reviewed-by: Adam Langley <agl@google.com>

Caught by clang scan-build.

Change-Id: I4f10c879dc137d4a14a7a395764d28e5caa033ff
Reviewed-on: https://boringssl-review.googlesource.com/1342
Reviewed-by: Adam Langley <agl@google.com>

PR: #3397

(Imported from upstream's 47b9e06cfd)

Change-Id: I92d46a3132233c179f4b708d506bfb7212c26a33

This ensures high performance is situations when assembler supports
AVX2, but not AD*X.

(Imported from upstream's 82a9dafe32)

Change-Id: Ie67f49a1c5467807139b6a8a0d4e62162d8a974f

It's not clear whether this inconsistency could lead to an actual
computation error, but it involved a BIGNUM being passed around the
montgomery logic in an inconsistent state. This was found using flags
-DBN_DEBUG -DBN_DEBUG_RAND, and working backwards from this assertion
in 'ectest';

ectest: bn_mul.c:960: BN_mul: Assertion `(_bnum2->top == 0) ||
(_bnum2->d[_bnum2->top - 1] != 0)' failed

(Imported from upstream's 3cc546a3bb)

Initial fork from f2d678e6e8 (1.0.2 beta).

(This change contains substantial changes from the original and
effectively starts a new history.)