Bring the overflow behavior in bit shifts in sync with std

[fjarri]

A part of #268
Fixes #121

• const fn bit shifts for Uint return the overflow status as CtChoice (and set the result to zero in that case, which is documented, so it's a part of the API now). Option would be better for the vartime shifts, but its methods are not const yet in stable.
• shl/shr for BoxedUint return (Self, Choice) (not CtOption since most of its methods need the type to be ConditionallySelectable, which BoxedUint isn't). The vartime equivalents return Option<Self>.
• operator impls panic on overflow (which is the default behavior for built-in integers)
• made the implementations in uint/shl.rs and shr.rs more uniform and improved vartime shift performance (before it was calling a constant-time shift-by-no-more-than-limb which added some overhead)
• improved constant-time shift performance for BoxedUint by reducing the amount of allocations
• added an optimized BoxedUint::shl1() implementation
• added some inlines for Limb methods which improved shift performance noticeably
• added more benchmarks for shifts and simplify benchmark hierarchy a little (create test group directly in the respective function)
• fixed an inefficiency in Uint shifts: we need to iterate to log2(BITS-1), not log2(BITS), because that's the maximum size of the shift.
• Renamed sh(r/l)1_with_overflow() to sh(r/l)1_with_carry to avoid confusion - in the context of shifts we call the shift being too large an overflow.

[tarcieri]

I think these are reasonably OK things to bring in line with std

[tarcieri]

As a convention I'm a fan of putting this sort of output parameter on the end, at least as far as an output buffer which is simply written into otherwise uninitialized, though I will acknowledge that's inconsistent with *_assign APIs, which operate on &mut self (and might those be applicable here?)

[fjarri]

It's not exactly assign, since it writes in a new buffer. But I don't mind changing the argument order, it's a private method anyway.

The reason it's not assign is because I wanted to optimize the cache usage, and in some cases it's impossible to do the forward iteration inplace.

[fjarri]

Running the benchmarks vs master, and while most of them improved, there are some regressions in Monthomery ops with BoxedUints. Investigating now.

[fjarri]

Hm, I was comparing the wrong commits. But it seems that there was a massive performance drop in "Montgomery arithmetic/multiplication, BoxedUint*BoxedUint" testcase between b169d2f and 1a0399d

[tarcieri]

@fjarri was it 2070407? That recalibrated the benchmarks using a larger input, so any of the earlier benchmarks aren't relevant, you'd have to revert the implementation and compare (but they were busted anyway, because they weren't using black_box)

[fjarri]

Yep, I bisected to that point too, seems to be the reason.

[tarcieri]

Looks fine now aside from the commented out test