cardano-crypto-peras: add base types

[gdeest]

Description

Replace stub Peras base types base real types (taken from ouroboros-consensus). cc @agustinmista

This moves the Peras certificate and vote types out of ouroboros-consensus and into cardano-crypto-peras, so that the ledger can keep certificates typed in the Dijkstra block body instead of as opaque bytes.

CBOR instances removed from initial draft (these will go in cardano-ledger-binary as per the Leios example).

The voters bitmap is built on Data.Bitmap from (unmerged) #700, so this PR includes #700's commits for now.

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages.
  New section is never added with the code changes. (See RELEASING.md)
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated.
  If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• Self-reviewed the diff

[agustinmista]

Hey! Nice job!

I have a couple of comments, mostly around serialization and documentation.

In addition:

• for consistency I think we should also bring the PerasVote definitions here.

• we recently introduces a size upper bound for certs here and here. We might want to bring those definitions along with these changes (CC @nbacquey).

[lehins]

Please look into cardano-crypto-leios package to see if there an opportunity for deduplication of logic, there is also a custom implementation of bitmaps

[gdeest]

Please have a look at #700 . The bitmap there should be usable by Leios as well.

[agustinmista]

Great work!

Some questions:

• Should we change the base of this PR to sit on top of #700? It should be possible to create a PR stack from there and merge all in one go if needed.

• Do you anticipate any issue when replacing the types in consensus with these?

[agustinmista]

Q: is this intentionally different from (..)?

[gdeest]

* Should we change the base of this PR to sit on top of #700? It should be possible to create a PR stack from there and merge all in one go if needed.

That would make definitely make sense (I am not too familar with the GitHub PR stack feature yet and it did not come to mind).

* Do you anticipate any issue when replacing the types in consensus with these?

None at all: I already have a prototype for the changes.