Cardano Updates

Follow-up to #119 that makes sure that we call `cryptoInit` before all
test suites and executables.

As for why we didn't notice that this was missing for e.g. db-analyser
so far: According to the cardano-base maintainers, not calling
`cryptoInit` does at least not cause random segfaults, but may impact
performance and cryptographic security.

Part of
[ouroboros-network#4006](https://github.com/input-output-hk/ouroboros-network/issues/4006)

Adds a strictness annotation in
`Ouroboros.Consensus.Util.MonadSTM.StrictMVar.updateMVar` to force the
value we're putting into the `StrictMVar` (`'a`) before checking its
invariant. This function isn't commonly used in ouroboros-consensus, but
was causing `Ouroboros.Consensus.Mock.Node.Praos.praosBlockForging` to
violate its NoThunks invariant during tests.

`LedgerTable`s have the same structure, regardless of the `l` type
parameter. Instead, we now have just one `LedgerTables` `newtype`, and
we can cast between `LedgerTables` with different `l` parameters as long
as the types of keys and values inside the `LedgerTables` match.

Also: provide instances for `H2K` classes.

higher-order, double keyed functors over bifunctors.

Later commits will define instances of these classes for `LedgerTables`.

yes, this is an odd-looking change. it's not unreasonable to assume that forcing !(!a', b) inside the atomically block will force the new value before putting it into the MVar, but there's actually an additional closure constructed (with a dependency on a') that will only force a' when *it's* evaluated! in order to ensure that we're forcing the value inside the MVar before calling checkInvariant, we need an additional bang outside the atomically block, which will correctly force a' before checkInvariant looks to see if it's been evaluated or not. without this change, it's possible to put a lazy value inside a StrictMVar (though it's very unlikely that this has happened in the past in production environments because this intermediate unforced closure is optimized away at -O1 and above)

We depend on an unreleased version of `strict-mvar` and we create a new
module for `StrictMVar`s with `NoThunks` invariants. We also add a flag
`checkmvarnothunks` that acts as a switch for whether we want to run the
invariant checks or not. By default, these checks are off, since we do
not want to perform these checks in production.

 - Update flake pins
    - iohk-nix: libsodium-vrf is now pinned differently
 - GHC 9.2.8 (fixes a segfault on some recent Linux kernels)
 - HLS 2.0.0.0

 - Update flake pins
    - iohk-nix: libsodium-vrf is now pinned differently
 - GHC 9.2.8 (fixes a segfault on some recent Linux kernels)
 - HLS 2.0.0.0

We could also share a common "setup" function across all executables, but we
currently don't need it for anything else.