💡 `indexed_handler`: RLE bitset alternative

[lukevalenty]

The current bitset implementation operator& performance and storage memory scales linearly with the number of callbacks.

An alternative RLE bitset implementation can provide better than linear scaling in both performance and memory.

The following guidelines should be followed to ensure efficient design:

1. RLE bitset construction must be constexpr.
2. Each RLE bitset struct must fit within a machine register or less. The struct itself should contain an offset into the shared RLE data table and a length.
3. Storage for the RLE bitset must be allocated outside of the RLE bitset element itself. The base pointer of the RLE data table is known to the RLE bitset at compile time (passed as template parameter, for example.) Multiple RLE bitset instances may share the same RLE data table, but can contain different offsets and lengths. Multiple RLE bitsets may share overlapping or identical spans of the table.

[AshleyRoll]

As discussed Luke, I'll take a swing at this.

Some notes from our chat:

• RLE Encoding should be based on std::bytes, for decoding speed, avoiding complex bitwise operations in the critical path
  IE: Assume leading 0s, then first byte of encoding is number of 0 bits, then next byte is number of 1s.
• Will need an iterator based traversal that can be used to build bitwise operators (or, and, etc)
• Ideal if it were possible to traverse an arbitrary number of these iterators in "lock step" to support efficient multi-way intersection calculation, zip like algorithm.
• Future Encoder optimisation might be to search for common bit patterns and reuse that encoding