Cardano Updates

This is in preparation for weighted chain comparisons.

Previously, we triggered ChainSel for all successor blocks of the immutable tip,
which in particular includes the oldest header on our selection (that is not yet
immutable). This is fine semantics-wise, but a bit weird that the block we are
performing chain selection for might not actually be part of the `ChainDiff`
that we are adopting. In particular, it is not true that all suffixes in the
candidate `ChainDiff`s intersect as one might expect.

For example, suppose that `k=2` and that our selection is

```
A ] B :> C
```

and the VolatileDB furthermore contains blocks `D` and `E` with `B :> D` and `C
:> E`. Then, when we trigger ChainSel, we trigger it for `B` (the only successor
of the immutable tip), and the ChainSel logic builds the following `ChainDiffs`:

 - `ChainDiff { getRollback = 1, getSuffix = B ] D }`
 - `ChainDiff { getRollback = 0, getSuffix = C ] E }`

Note that the suffixes do not intersect.

Therefore, motivated by future work (weighted chain selection) which relies on
these fragments to intersect, we refactor this code to trigger chain selection
for all blocks that are a successor of a block on our selection (while ignoring
blocks on our selection), which is semantically equivalent (but we potentially
consider candidates in a different order than before, which is acceptable while
syncing via Genesis). This ensures that all `ChainDiff` suffixes intersect.

In the scenario above, this is achieved by the fact that we separately trigger
chain selection for `D` and `E`.

Different LedgerDB backends will manage snapshots in different ways. In
particular, before LSM trees each snapshot was fully contained in a directory in
the ledger folder of the ChainDB.

However LSM trees store part of the snapshot in the LSM database, which might be
somewhere else.

The SnapshotManagement record of functions provide a common interface for
managing the snapshots.

LSM trees will need some additional information in some functions to emulate
IndexedMemPack.

Also taking a snapshot of a handle might not provide a CRC anymore.

LSM trees use an ordering different than the Haskell `Ord`. This commit enriches
the type returned by range reads so that the maximal key is returned, which is
then given back to the next iteration of the range reading loop.

LSM trees require a Session which we don't want cardano-node to create. We
therefore define `LedgerDbBackendArgs` which will be given by the node to us.