Cardano Updates

Moved from hydra-node library to the hydra-node:testlib
component.

Instances and generators that were in eg `Hydra.X.Y.Z` in
`hydra-node/src` are now in a module named `Test.Hydra.X.Y.Z`
located in `hydra-node/testlib`.

Instead of reviewing, I thought I'd contribute the changes I would like
to see on #2407 directly. This cleans things up and reduces the diff as
much as possible to `master`. Also, the `lastKnown :: ChainPointType tx`
approach is taken here (originally done by @ffakenz, but moved away
from).

This approach is good because it requires minimal additional storage and
memory profile due to the stored `TickObserved` state changes are only
extended by a block hash (change from slot to point). Convince yourself
by trying this on this PR vs. #2407 :

```shell
cabal run hydra-cluster -- --devnet --publish-hydra-scripts --state-directory tmp-cluster
tail -f tmp-cluster/state-1/state| jq
```

Obviously, the list of points used to try to find an intersection is
still not big, but this was captured in #2437 and should be resolved
later (using chain re-orgs of varying sizes). I have also noticed this
problem when doing this PR, which should also be considered in #2437:


https://github.com/cardano-scaling/hydra/blob/2b6ea469b0ce02dea5b7879b826fed84de52737c/hydra-node/src/Hydra/HeadLogic.hs#L1999-L2000

There are few things still left to do (for @ffakenz after merging this
into #2407):

- [ ] hydra-node/src/Hydra/Chain/Blockfrost.hs FIXME: should start at
'last' and try older and older points
    - best effort implementation and could be improved in #2437
- [x] hydra-node/test/Hydra/API/HTTPServerSpec.hs FIXME: this can't be
correct anymore
- [x] hydra-node/test/Hydra/API/ServerSpec.hs REVIEW: is this really
needed and why can't we stick with dummyChainHandle as it was before?

---

<!-- Consider each and tick it off one way or the other -->
* [x] CHANGELOG updated or not needed
* [x] Documentation updated or not needed
* [x] Haddocks updated or not needed
* [ ] No new TODOs introduced or explained herafter

This was resolving an issue where (likely for another reason), rapidly
submitted transactions required re-enqeueing of ReqTx inputs.

Hypothesis: When the input queue was not bounded, another bounded
queue (in Hydra.Logging) was creating delays leading to the re-enqeued
retrying of applying transactions start to fail (because they time out).

It is not known why the chain of transactions we used (see hydra-cluster
bench) was even requiring the re-enqeuing in the first place though.