The *idea* of `big_digit` and its type aliases is that we may someday
use something other than `u32` in the representation, perhaps even
different sizes for different targets. That's still a possibility, but
I think it's not really feasible to expose this variation in the public
API. Calling `BigUint::from_slice([1, 2, 3])` is only meaningful if you
know what that size is, and users can't really alternate this kind of
thing based on a type definition. So for now, we just commit to `u32`
units in the public API, no matter what we may do internally.
This removal is a breaking change, part of the 0.2 semver bump. If I'm
wrong and somebody can show a compelling use case for `big_digit`, we
can always add things back into the public API later.
The test modules were getting huge, and some of its functions were
actually a huge amount of code due to macros, causing tests to take a
long time just to compile. They are now separated into a few different
tests, and the scalar macros especially are now expanded more sparingly
in just a few `check()` functions.
Test compile times for me went from about 25 seconds to 1.5s in debug
mode, and from 300 seconds (!) to about 8s in release mode.
This performs modular exponentiation on signed `BigInt`. The exponent
must be positive, and the modulus must be non-zero. The implementation
leverages `BigUint::modpow`, fixing the signs as needed afterward.
