[Peras 27] Split degenerate BlockSupportsPeras instance

[agustinmista]

This PR has the main goal of removing the existing degenerate forall blk. BlockSupportsPeras blk instance and replace it with separate, independent ones for the several block types in the codebase that need it.

To aid with this process, we have made a couple of preliminary changes:

• Moving base Peras types into a separate O.C.Peras.Types module to keep O.C.Block.SupportsPeras as focused on the blk-dependent API as possible.
• Consolidating all the HasPeras(Vote|Cert)X classes into two, IsPerasVote and IsPerasCert, grouping all the necessary non-crypto-related projections needed to operate on Peras votes and certificates.
• Removing the PerasCfg blk associated type, in favor of keeping things simple and using the monomorphic PerasParams for now. These will likely need a major overhaul in the future when on-chain governance of these parameters becomes necessary.
• Introducing dedicated modules for MockPeras(Vote|Cert)s, containing the non-crypto mocked Peras votes and certificates that were previously hardcoded everywhere. These will still be used for certain (mostly test) block types.
• Provide an "empty" default BlockSupportsPeras instance defined in terms of Void, so Peras votes, certs, and errors are uninstantiable and can be discharged via absurd.

With this in place, the remaining changes mostly encompass the plumbing needed after removing the existing BlockSupportsPeras instance and replacing it with dedicated ones. Concretely:

• ByronBlock uses the "emtpy" instance
• ShelleyBlock proto era uses a mocked instance (to be replaced with a concrete one using real type for era ~ Dijkstra and empty ones for every other era. (@tbagrel1 is working on this on a separate PR)
• HardForkBlock xs uses a mocked instance, but will be replaced with a compositional one defined around the two previous ones (also WIP)

On the testing side:

• BlockA and BlockB both use the "empty" instance
• DualByronBlock uses the "empty" instance
• O.C.Mock.Ledger.Block.SimpleBlock c ext uses the "empty" instance
• O.C.Storage.TestBlock.TestBlock uses a mocked instance (now with a properly instantiated getPerasCertInBlock)
• Test.Util.TestBlock.TestBlockWith ptype uses a mocked instance (without any support for certificates in blocks, as it's not needed for any of the existing tests)

Finally, some general notes (notice that some of these are already covered by new issues linked in the comments below):

• There is a substantial number of instances involving type families that had to be derived using standalone deriving statements now to keep GHC happy.
• BlockSupportsPeras is still missing a forgePerasVote method. This will become evident soon when trying to write a blk-generic voting thread (BlockSupportsPeras currently misses a forgeVote method tweag/cardano-peras#248)
• Some of the new BlockSupportsPeras instances are defined via orphans in dedicated modules. This is because:
  • SerialiseNodeToNodeConstraints blk now requires SerialiseNodeToNode (PerasVote blk) and SerialiseNodeToNode (PerasCert blk) which are only in scope after PerasVote blk and PerasCert blk are established when defining BlockSupportsPeras blk
  • Some SerialiseNodeToNodeConstraints instances are already defined as orphans in their own dedicated modules, forcing us to create a new module or to define BlockSupportsPeras blk in the same one as SerialiseNodeToNodeConstraints blk (confusing!). We might be able to rearrange constraints to avoid this, but that would probably mean adding SerialiseNodeToNode (Peras(Vote|Cert) blk) as superclasses to a type-class higher-up in the chain.
  • We favored tight constraints over "umbrella" ones as much as possible to avoid having to implement unnecessary/unrelated interfaces for test blocks as much as possible.
• Mocked votes and certs are trivially validatable without errors (technically, with uninstantiable errors if being pedantic). For this to work, MockPerasVote carries its own stake. Please note this is not the case for real votes, as their stake is retrieved from the stake distribution after validation.
• Some Peras... types will become redundant and get removed in a later PR when we start integrating components.

[agustinmista]

Closing in favor of #2067