Square/small-exponent cases over 128B-1024B moduli run at
~210-255 Mgas/s vs ~400 Mgas/s for well-amortized exponents because
the Montgomery setup (base->Montgomery division + convert-back AMM)
is not amortized over few exponentiation steps. This is the regime
erigon's modexp integration routes to Go math/big.

Adds nagydani-1/2/3/5 square and pow0x10001 variants, mod-264-exp-2,
and an even-modulus (CRT path) case.

The benchmark filled the base with 0xff, which equals the modulus's
high bytes, so base == modulus (base ≡ 0) for odd moduli and a tiny
residue otherwise. Intermediate values then stayed trivially small,
hiding the cost of division-based reduction in value-sensitive code
paths. (Montgomery is value-insensitive, so its numbers were unaffected.)

Use 0xab so the base is a generic full-size residue below the modulus.

For a tiny exponent the Montgomery setup — a base->Montgomery division
plus a convert-back multiply — is not amortized over the few
exponentiation steps. For squaring (exponent <= 3) over a large odd
modulus, plain square-and-multiply with division reduction (mul + rem)
is faster.

Gated on exp.bit_width() <= 2 AND odd part >= 512 bits, and applied to
the odd part only (the power-of-two part keeps its division-free path).
Outside this regime Montgomery is equal or better, so it is kept.

Squares over 128B-1024B odd moduli: 1.5-1.7x (the cases erigon's modexp
integration routed to Go math/big). pow0x10001 and larger exponents,
small moduli, and pow2-heavy moduli are unchanged.

rem() is generalized to accept an equal-width dividend, which a reduced
product can be.