SQLite: Replace in-memory table with the old BTreeMap-powered in-memory cache

[badboy]

This seems to be a lot faster.
But it does NOT yet do the full label check.

One thing why even with delay_ping_lifetime_io the new code is slower is that we still do the SQLite machinery, which can get heavy I guess.
This re-implements the same BTreeMap-powered cache again, avoiding SQLite for all those in-memory recordings.
It does not yet do the proper label check, but it's good enough for a first test run to see if it gets us closer to the old numbers again.

On my mac I ran the benchmarks as following:

Get the Rkv baseline:

cargo benchmark --bench lifetime_buffering -- --save-baseline rkv

Then run again against the SQLite code:

cargo benchmark --bench lifetime_buffering --features sqlite -- --baseline rkv

Results from today:

IO delay/no delay       time:   [6.5278 µs 6.5750 µs 6.6318 µs]
                        change: [−94.225% −94.062% −93.926%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  2 (2.00%) low severe
  6 (6.00%) high mild
  4 (4.00%) high severe
IO delay/delayed - no flush
                        time:   [136.71 ns 137.11 ns 137.52 ns]
                        change: [+1.3290% +1.8158% +2.2606%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
IO delay/delayed - flushed after 1000
                        time:   [153.15 ns 153.58 ns 154.02 ns]
                        change: [−39.949% −39.618% −39.297%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
  1 (1.00%) high mild

I'm not sure why the no flush benchmark regressed. I did have it at least within noise up to 1.5% faster.
But that's also not a mode any app would run in anyway.