Cardano Updates

This runs a *single* chain selection to select the best chain involving
potentially LoE-postponed blocks. This way, transient chain switches (ie
adopting one chain in one `chainSelectionForBlock` call, only to select an even
better one just after in the same invocation of `chainSelSync`) are avoided.

Currently, the LoE reports the block that we triggered chain selection for here,
but this is somewhat misleading.

No need to pass it to `switchTo`; it provides no information that is not already
derivable from `ChainDiff`.

This is just factoring out shared code between `addToCurrentChain` and
`switchToAFork` into a new top-level definition.

This way, `chainSelectionForBlock` is now rather streamlined:

 1. Some easy checks on the new block (ignore if too old or invalid).

 2. `constructPreferableCandidates` to get all candidates involving the new
    block which are preferable to the current selection.

 3. `chainSelection` to get the based valid one of these candidates.

 4. `switchTo` to adopt the candidate as our new selection.

The `AndLedger` part isn't actually needed, so we can simply remove it, and eg
no longer need to invoke `LedgerDB.withTipForker` in `chainSelectionForBlock`,
simplifying the code.

This is purely moving `switchTo` to the top level, no logic changes.

Again, just factoring out some existing code to reuse it in a follow-up commit.

This runs a *single* chain selection to select the best chain involving
potentially LoE-postponed blocks. This way, transient chain switches (ie
adopting one chain in one `chainSelectionForBlock` call, only to select an even
better one just after in the same invocation of `chainSelSync`) are avoided.

Currently, the LoE reports the block that we triggered chain selection for here,
but this is somewhat misleading.

Again, just factoring out some existing code to reuse it in a follow-up commit.

This is just factoring out shared code between `addToCurrentChain` and
`switchToAFork` into a new top-level definition.

This way, `chainSelectionForBlock` is now rather streamlined:

 1. Some easy checks on the new block (ignore if too old or invalid).

 2. `constructPreferableCandidates` to get all candidates involving the new
    block which are preferable to the current selection.

 3. `chainSelection` to get the based valid one of these candidates.

 4. `switchTo` to adopt the candidate as our new selection.

No need to pass it to `switchTo`; it provides no information that is not already
derivable from `ChainDiff`.

This is purely moving `switchTo` to the top level, no logic changes.

The `AndLedger` part isn't actually needed, so we can simply remove it, and eg
no longer need to invoke `LedgerDB.withTipForker` in `chainSelectionForBlock`,
simplifying the code.

This is a remnant of an early version of the LoE that wasn't "idempotent", ie it
was sometimes necessary to trigger chain selection after having added a block.
This has not been the case for a long time, so this is semantically dead code.

Removing it reduces the amount the trace output in counterexamples.

So far, the smoke test fails because of "undefined" placeholders in
Agency proofs. It will be automatically resolved when ObjectDiffusion
implementation in ouroboros-network is improved