Cardano Updates

- avoids computing random values over and over

This should be the same semantics as before, but with a list of points
coming from the ChainStateHistory (built from persistence)

Co-authored-by: Sebastian Nagel <[email protected]>

- removed mkChainState from chain handle
- passing initialChainState via API layer

This should retain the original logic where start chain from was used if
it was newer than the last known persisted point.

This should keep the overhead minimal by only adding block header hashes
next to slot numbers. It remains a breaking change though.

This does not force the Simple instance to use the Cardano
type (ChainPoint) and prepares usage of the parametric type
ChainPointType in the Hydra.Chain interface.

This does not break abstraction and expose cardano specifics on the
websocket server. Also, we can use the NodeState to report on this and
don't need to provide the chain state history (avoids coupling).

This is deliberately a ChainPointType and not a ChainStateType because
modifications to the state-to-keep-track are only expected upon
observations and rollbacks.

> because now history is bounded we can safely use all its points
as candidates to find an intersection

The history does not contain all ticked points anymore, but only states
when observations were made an the last known point.

If that is too little, we can aggregate the last x points to try to find
an intersection on demand. See
https://github.com/cardano-scaling/hydra/issues/2437 for more details

> to work with chain state instead of chain slot

> keep track of latest known chain state instead of chain point

This reverts commit 81b53932217f368f705e9410f326d31bd27fddc4.