Factor out class ShelleyBasedBlock and type family ShelleyBlockLedgerEra

[dnadales]

Pending change from #934 (comment)

[amesgen]

We could give this class "more power", ie make its superclass constraints stronger, eg use ShelleyCompatible instead of just ShelleyBasedEra:

Suggested change

	class
	( ShelleyBasedEra (ShelleyBlockLedgerEra blk)
	, blk ~ ShelleyBlock (BlockProtocol blk) (ShelleyBlockLedgerEra blk)
	) => ShelleyBasedBlock blk
	instance ( proto ~ BlockProtocol (ShelleyBlock proto era)
	, ShelleyBasedEra era
	) => ShelleyBasedBlock (ShelleyBlock proto era)
	class
	( ShelleyCompatible (BlockProtocol blk) (ShelleyBlockLedgerEra blk)
	, blk ~ ShelleyBlock (BlockProtocol blk) (ShelleyBlockLedgerEra blk)
	) => ShelleyBasedBlock blk
	instance ( proto ~ BlockProtocol (ShelleyBlock proto era)
	, ShelleyCompatible proto era
	) => ShelleyBasedBlock (ShelleyBlock proto era)

This might come in handy in a future use case where we want to call a function that requires ShelleyCompatible and not just ShelleyBasedEra in an SOP combinator.

[jasagredo]

I also proposed the same. I do wonder if this is not equivalent to requiring it in the constructors? as in:

data ShelleyBlock proto era where
  ShelleyBlock :: ShelleyCompatible proto era => 
    { ... } -> ShelleyBlock proto era

leaving that aside, it might be intereseting to provide instances for Header (ShelleyBlock ...) and LedgerState (ShelleyBlock ...)? I feel like this might simplify some aux classes we might have around.

[jorisdral]

I think one should prefer function constraints, not constraints on constructors. They are not entirely equivalent

Most of the places where I use constraints inside constructors is when dealing with existentials or Dicts