As a preparation for memory behavior optimizations, we first add a set
of benchmark tests to establish a baseline against.
The benchmarks determine the speed and memory usage of writing different
sized batches to the bbolt index as well as the random access latency
for retrieving entries from the index.

We want to isolate the code that reads from/writes to the index bucket
within the headerIndex type. We prepare to do so by extracting re-usable
code into methods.

We want to isolate the code that reads from/writes to the index bucket
within the headerIndex type. We prepare to do so by extracting re-usable
code into methods.

Now that we have methods for accessing the index buckets, we use those
in the blockHeaderStore instead of manipulating the DB directly.

With this commit we store the index keys (hash->height) in sub-
buckets with the first two bytes of the hash as the bucket name.
Storing a large number of keys in the same bucket has a large
impact on memory usage in bbolt if small-ish batch sizes are
used (the b+ tree needs to be copied with every resize operation).
Using sub buckets is a compromise between memory usage and
access time. 2 bytes (=max 65535 sub buckets) seems to be the
sweet spot (-50% memory usage, +30% access time). We take the
bytes from the beginning of the byte-serialized hash since all
Bitcoin hashes are reverse-serialized when displayed as
strings. That means the leading zeroes of a block hash
are actually at the end of the byte slice.