Cardano Updates

> the former gets updated upon ticks the later upon head transitions observed, which
usually is older than ticks

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.

Improves logging throughput by combining 64KB block buffering with batch
draining of the `TBQueue`.

Benchmark (LOG_N=100000, --time-limit 10) shows buffered+batched ~196 ms
vs flush-each ~543 ms (~2.8× faster). This keeps log output format and
monitoring behavior unchanged, but logs may appear in bursts and have
slightly higher latency.

If we exclude batching the win is ~1.28x 

<!-- Describe your change here -->

---

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

> when calculating the slot drift

* extended NodeSynced and NodeUnsynced with time and slot drifts
* added Haddocks to both currentSlot and currentChainTime
* made NodeState.currentChainTime non optional
* defined initialChainTime = posixSecondsToUTCTime 0

> NodeState now tracks currentChainPoint :: ChainPointType tx, instead of currentSlot :: ChainSlot + currentChainTime :: Maybe UTCTime
> NodeSynced and NodeUnsynced now carry ChainPointType tx, instead of chainTime :: UTCTime
> extended IsChainState class with chainPointTime :: ChainPointType tx -> UTCTime
> initialChainTime = posixSecondsToUTCTime 0

This reverts commit 037aea1d9f15f65db00113f0606f9e09d0b03548.