We had an instance of `SingleEraBlock` for `ShelleyBlock` that was parametric in
the era, causing all Shelley-based eras (Shelley, Allegra, Mary) to have the
"Shelley" name.

Fix this by adding a `shelleyBasedEraName` method to the new `ShelleyBasedEra`
class, which combines the new method with the ledger-defined class of the same
name. See its docstring for more details.

Make the following change:
```diff
-      , pInfoBlockForging :: [m (BlockForging m b)]
+      , pInfoBlockForging :: m [BlockForging m b]
```

This is more general and will allow us to, e.g., do create multiple
`BlockForging` records in one monadic call.

For each era, there will be a thread periodically trying to evolve the KES key
and securely forget the previous one.

Previously, we required a set of credentials for each Shelley-based era, e.g.,
Shelley, Allegra, and Mary. In practice, most users will want to use the same
credentials for, e.g., Shelley and Allegra. However, when using the same
in-memory KES key for multiple eras, multiple threads will try to evolve and
secure forget the *same KES key*. Depending on the implementation of secure
forgetting for KES keys, this could lead to segfaults.

Instead of having a separate set of credentials per Shelley-based era (this
remains independent of how Byron credentials are handled), we now share a single
set of credentials for all of them. We use the new `shelleySharedBlockForging`
function to do this in a safe way, i.e., by sharing the same thread-safe
`HotKey` across the threads.

We refactor the protocol parameters for Shelley/Allegra/Mary to handle the
shared key: we now have a `ProtocolParamsShelleyBased` record which contains
everything needed for a Shelley-based chain, i.e., the genesis config and the
credentials. This record should be combined with the right era-specific ones.
This also paves the way for adding a Mary-only mode.

This will make it possible to use it in combination with `NP`.

Instead of a different thread per era, the hard fork combinator can now combine
`BlockForging` records from multiple eras into one `BlockForging` record which
picks the appropriate `BlockForging` based on the current era.

This means that the KES key shared by the Shelley-based eras will only be tried
to be evolved once, instead of once for each Shelley-based era (in the previous
approach, all threads would try to evolve it, but all but one would be an
identity operation). This should also improve tracing: instead of tracing
messages for each era, only messages of the current era are traced.

Note that multiple credentials *per era* (i.e. to benchmark multiple stakepools
on one node) will still result in multiple forging threads.