Define a custom Cardano-like era with long TLL for benchmarking it

[dnadales]

There is a suspicion that the integration layer of the node might be invoking computations that are proportional to the type-level lists (TLL) that are used in the hard-fork combinator (HFC).

We need to define a custom Cardano-like era that can be run with our system-level benchmarks so that we can compare its performance with that of the Cardano node.

If there is a cost introduced by the HFC then we want to exaggerate its impact, hence the preference for a long TLL.

[amesgen]

Some pointers regarding the topic of performance improvements in this area:

• sop-core PR to represent NS/NP more efficiently: https://github.com/well-typed/generics-sop/pull/129

  We mostly use strict versions of NS/NP in strict-sop-core, so these would need to be changed in a similar fashion.

  This might result in both speed and memory improvements.

• A more modest idea is to "reverse" the structure of our NSs such that accessing the most recent era can happen in constant time. See e.g. here for some discussion.

• Since #951, UTxO-HD uses a custom representation for TxOuts (a custom sum type instead of an NS). Maybe the compact representation for NS could make this optimization unnecessary, simplifying the code.

  cc @jorisdral @jasagredo

[amesgen]

Also: We have a relatively small upper bound on the number of eras we can support ATM regarding serialization: #328