Add index benchmarks for composites of primitives (#4248)

# Description of Changes

The PR adds some benchmarks meant to compare how we encode composite
indices for primitive types today (`_AV`) versus how we intend to store
them in the future.

These benchmarks sample the standard uniform distribution for some
static types, e.g., `(i32, i32, u64)` and then either converts them to
how we store keys today (`_AV`, stands for `AlgebraicValue`), or encodes
them into a byte-array (`_Enc`, stands for "encoded), e.g., `[u8; 16]`
in the case of the bitcraft index, which is what the future optimization
would entail.

The comparison for each type is then between `_AV` and `_Enc`. 
Here are some numbers on an i9-14900K:

```
IFoldHash<I32xI32xU64_AV>/insert_random
                        time:   [85.817 ns 87.344 ns 88.648 ns]
IFoldHash<I32xI32xU64_Enc>/insert_random
                        time:   [41.329 ns 42.217 ns 43.120 ns]
IFoldHash<I32xI32xU64_AV>/seek_random
                        time:   [108.48 ns 111.47 ns 114.05 ns]
IFoldHash<I32xI32xU64_Enc>/seek_random
                        time:   [43.468 ns 45.974 ns 48.468 ns]
IFoldHash<I32xI32xU64_AV>/delete_random
                        time:   [112.36 ns 120.10 ns 127.67 ns]
IFoldHash<I32xI32xU64_Enc>/delete_random
                        time:   [49.078 ns 51.745 ns 54.182 ns]
```

These benchmarks strongly suggest that the future optimization will be
highly profitable.

# API and ABI breaking changes

None

# Expected complexity level and risk

0, not even trivial :)

# Testing

Nothing to test / this is benchmark code only.

Author: Centril