sstable: specialized index blockIter

[jbowens]

Implementing a specialized blockIter for index blocks should reduce the cpu cost of seeks:

1. Index blocks are dense. They tend to contain smaller keys (because their keys may be shortened by Comparer.Separator), and relatively small values (an encoded BlockHandle). This density means seeking within an index block has a higher cpu cost, and optimizations here can have an outsized impact on overall seek cpu cost.
2. The Trailers of keys within index blocks are always ignored. There's no need to decode them.¹
3. The values of keys in index blocks are always inlined, so we can avoid the overhead associated with checking whether a value is inlined or out-of-band and overhead from returning base.LazyValues.
4. Related to ¹, we do not need to perform obsolete bit checks or obsolete key kind transformations introduced in sstable,db: introduce a sstable-internal ObsoleteBit in the key kind #2559 for index block keys.
5. We write index blocks with a restart interval of 1. Besides encoding the offset of every key, this forces every key to be written in whole without any prefix compression. We can avoid the overhead of considering whether a key might be prefix-compressed.²

The downside is code duplication. But there are a few factors that make this more tolerable:

1. We use a subset of the blockIter interface with index blocks (eg, no NextPrefix, no SeekLT), so it's not quite doubling the interface surface area.
2. The non-trivial code surrounding lazy-value handling and reading does not need to be duplicated.
3. The code around prefix sharing does not need to be duplicated.

Once we have a specialized index block iterator, it's easier to make changes to the index block format. There are two optimizations available right off the bat:

1. Since the key trailers are unused¹, we can omit them entirely.
2. Since prefix compression is unused², we can omit the shared bytes varint.

Jira issue: PEBBLE-42

[jbowens]

Relates to #97

[jbowens]

We might also consider entirely different formats for index blocks, such as an adaptive radix tree. With sufficient space savings, could we remove support for two-level indexes and simplify the sstable iterator?

Somewhat relates to #2632 by achieving similar key compression within the index block.

[jbowens]

Moving into 'Next' category because this will fall out of the columnar block format work.