Cardano Updates

These are seemingly only used by cardano-api

This will be emitted whenever the forge decision logic decides to
include a certificate in a block body.

This allows us to keep track of the total weight against a threshold to
certify (also in the visualization).

We might want to drop / not allow votes from previous epochs as the
committee can change and nodes would come silently to different
conclusions depending on their selected tips.

Real signing keys requires some more bytes. This is still unsafe of course.

The LeiosVoteState now drives us to add cryptographic signatures so we
cannot fake the voterId (index in the committee) without also having the
private key.

Provide access to the committee using the HasLeiosVoting type class and
via the ChainDB access to the tip's ledger state.

Enumerating shelley / praos instances for HasLeiosVoting makes it very
clear that a committee is only expected to be selected in Dijkstra

This will be just enough to derive a committe.. if I just re-use the
pool key hash as the vote signing key of all pools and derive
verification keys this way (to still skip proper key registration).

This derives vote signing key from the cold key hash - obviously still a
dirty hack, but just fine to avoid doing key registration.

This class based approach mirrors other components of the consensus code
base where abstract code is made block-specific via type classes.