Simplify and automate protocol version handling

The protocol version is used in the following ways:
* It is put in the header of forged blocks to indicate which protocol version the node supports.

For Byron, the major/minor/patch version can only increase by exactly 1. So 0.0.0 -> 0.0.1, 0.1.0 -> 0.2.0, 0.0.0 -> 1.0.0 are allowed, but not 0.0.0 -> 0.2.0. current protocol version.

For Shelley-based eras, this can be any value that is greater than the current one. This means we could start a Mary-capable node with 4.0.0, even when only in the Shelley era.

* The ledger checks whether the current major protocol version is less than or equal to the maximum major protocol version.

* The ledger maintains the current protocol version. It can be voted on. A protocol version can change the behaviour of the ledger, including triggering a hard fork to another era.

We can simplify the handling of protocol versions in the following ways:

1. Instead of making the protocol version of each era configurable, we can define a static mapping from protocol version to era. This means users don't have to change their configuration files for upcoming hard forks and that they can't mess it up.

a. For Shelley/Allegra/Mary, we use 2/3/4. The `ProtocolParamsX` record will become empty.

b. For Byron, this is only used when forging blocks, so this only matters for testnets. We can just look at the current protocol version and increment the major protocol version by 1 when forging.

2. `TriggerHardForkAtVersion` no longer needs an argument, as the versions at which to trigger hardforks are known.

3. When using `TriggerHardForkAtEpoch`, we should update the protocol params in the ledger accordingly. At the moment this is not done, so when hardcoding all transitions in the chain, the protocol params in the Mary era will never have been updated.

This can be done in the ledger state translations.