Move arithmetic to its own crate

[myrrlyn]

As mentioned in #16, the default numeric arithmetic implementations may not be suitable for all use cases of bit sequences. Furthermore, the core crate does not include suitability as a numeric type in its design goals – the minimum product is a sequence of raw bits, with no further semantic information held in the sequence itself.

This issue proposes moving all numeric behavior out of the core crate, into a separate sibling crate (bitvec_arith? bitvec_num?) with wrapper types over BitSlice and BitVec that perform numeric arithmetic using the underlying sequences as the n-ary number storage.

[myrrlyn]

The implementation of AddAssign is currently a ripple-carry adder. This is a strictly linear O(n) operation in the length of the addends, and is the worst possible implementation of numeric addition. Use of a different addition algorithm, such as CLA trees, or the Kogge-Stone family, would allow for faster performance and enable parallelization.

[myrrlyn]

Issue #50 notes that comparison is lexicographic, not arithmetic. This makes for incorrect behavior when performing arithmetic governed by comparison!

This problem raises the severity of this issue. As such, I plan to remove the arithmetic implementations from this crate this year, ideally in the next release.

[myrrlyn]

Nobody has asked about varint support in the crate, so I'm going to close this.