Various low-level BitVector performance improvements

Various performance improvements to BitVector.

* Got rid of `AtomicLong` values in every BitVector for tracking size bounds. Since most BitVectors have a definite size (sole exception is `Append` nodes whose right branch is a `Suspend`), no sense in paying for constructing and updating these bounds for other constructors. See the `Append` implementation of `sizeLessThan`. It actually does not use `AtomicLong` for the size lower bound. Recomputation is okay, and the size lower bound starts out conservatively equal to the size of the left branch and can only increase monotonically. (Also okay if another thread observes the lower bound having the default long value of `0` - that is still an accurate if overly conservative lower bound)
* Converted pattern matching to use virtual method dispatch in a few places (while preserving stack safety)
* `toInt` and `toLong` got a minor performance boost due to removing some allocation during traversal, and using the new `getByte` function directly. There are probably some codecs that would benefit from using `getByte` directly, rather than calling `toByteVector`.

Amount of speedup really depends on what you are doing. Here's a [gist of logs from some integration tests](https://gist.github.com/pchiusano/b68ef3d2884d1ec165ab) - the only difference between those two runs is which scodec-bits jar is on the classpath. For very fine-grained decoding which do lots of take/drop, I'm seeing about a 3x improvement.