Hierarchy of EraTest classes

[lehins]

Similarly to [Era]Imp type classes we need to create a type class for each era in the testlibs that will be used throughout all of our tests.

1. In cardano-ledegr-core:testlib we need a new module Test.Cardano.Ledger.Era that will have a single
   type class with no methods, but a ton of superclasses for all of the core type families:

   class ( Arbitrary (Tx era)
         , Arbitrary (TxBody era)
         , ..
         , ToExpr (Tx era)
         , ToExpr (TxBody era)
         ...
         , EraTx era
         , EraTxBody era
         ...
         ) => EraTest era

   Plus whatever other constraints that are common between all eras
   It also needs to import any instances that are available for type classes that are listed as superclasses. Specifically Arbitrary and ToExpr

2. In cardano-ledger-[era]:testlib new module Test.Cardano.Ledger.Shelley.Era that will have a single type class with no methods (for now), but a ton of superclasses for all of era specific type families. Note that superclass constraints for concrete types should usually not be necessary, since such instances are usually defined for all eras anyways (eg. Arbitrary . Very important point here is that we should only include constraints that are tru for current and all subsequent eras. In other words avoid adding any supclass constraints for anything that was or will be deprecated in any of the subsequent eras. Good example is a ShelleyTxCert constraint, which Dijkstra era will not have an instance of. So, it should look something like that:

   class ( EraTest era
         , ShelleyEraScript era
         , Eq (StashedAVVMAddresses era)
         , Show (StashedAVVMAddresses era)
         , ToExpr (StashedAVVMAddresses era)
         , Arbitrary (StashedAVVMAddresses era)
         , ..
         ) => ShelleyEraTest era

If you are unsure whether a constraint should be there or not, just avoid adding it, because we can always add the missing ones later whenever we run into them

Uses cases for these type classes are:

• they can be used as super class constraints for [Era]EraImp type classes
• they can be used to avoid long type signatures like that
• They are easier to use at call sites that depend on a lot of nested Arbitrary or ToExpr instances for type families (like the use case above), which means it will be very useful for work in Remove Pretty from cardano-ledger-test #4966