Cardano Updates

Also uses BEGIN IMMEDIATE queries to detect contention when starting a
transaction.

This could be further improved by having only one writer thread.

This also moves the implementations into separate modules

This uses a more consistent generation of quantities and resembles the
concurrent access similar to the production code.

This is currently quite barebones, but gives us a good first numbers of
a reasonably respresentative scenario:

```
λ cabal bench leios-db-bench
Build profile: -w ghc-9.6.6 -O1
In order, the following will be built (use -v for more details):
 - ouroboros-consensus-0.27.0.0 (bench:leios-db-bench) (ephemeral targets)
Preprocessing benchmark 'leios-db-bench' for ouroboros-consensus-0.27.0.0...
Building benchmark 'leios-db-bench' for ouroboros-consensus-0.27.0.0...
Running 1 benchmarks...
Benchmark leios-db-bench: RUNNING...
LeiosDemoDb concurrent benchmark

Database setup:
  EBs pre-populated : 500
  TXs per EB        : 200
  Total TXs         : 100000

Concurrent workload per iteration:
  Active reader (×1): 10 rounds of filterMissingEbBodies (200+200) + filterMissingTxs (500+500)
  Writers       (×2): 20 insertEbPoint/insertEbBody/insertTxs each
  Readers       (×8): 30 lookupEbBody + 10 batchRetrieveTxs each

Runs: 1 warmup + 5 timed

Inserting EBs: 50 100 150 200 250 300 350 400 450 500 done
  run 1/5: 3.830633993 s
  run 2/5: 3.696195071 s
  run 3/5: 3.675190096 s
  run 4/5: 3.789160281 s
  run 5/5: 3.890996196 s
  => min=3.675190096 s  avg=3.7764351274 s  max=3.890996196 s
Benchmark leios-db-bench: FINISH
```

bump deps to cardano-node 10.7.0