Round up bits_precision when creating BoxedUint

[fjarri]

I understand that this change may be controversial, but let me just put it out there. The reason being, why panic when we don't have to, and also to prevent bugs when something works on a 32 bit but doesn't on a 64 bit target.

• BoxedUint::zero_with_precision(), one_with_precision(), max() round up bits_precision to a multiple of Limb::BITS. It's a little weird in the case of max(), but I am not sure this method should be public in the first place (and perhaps should be renamed).
• Support arbitrary bits_precision in BoxedUint::random() (generating a random number in range [0, 2^bits_precision)).
• Fix the tests in boxed/rand.rs which didn't actually test BoxedUint.
• Round up bits_precision when decoding BoxedUint from bytes, to match the constructors' behavior.
• Round up nlimbs() in the same way. Fixes nlimbs!() macro doesn't support rounding up to the limb size #258.

An option here is to keep the given bits_precision as a field in the BoxedUint without rounding it up. Then we will have to zeroize MSBs in arithmetic operations.

[tarcieri]

I'm generally OK with this. We had similar requests in the past: #258

[fjarri]

Should I add rounding up there too? I think it is self-evident that nlimbs!(127) does not produce an U127, but instead gives the number of limbs enough to fit 127 bits.

[tarcieri]

Should I add rounding up there too?

@fjarri sure, sounds good

[fjarri]

Done

[tarcieri]

@fjarri this needs a rebase now

[fjarri]

Rebased