Will be needed for constructing txs in later ledger eras.

Move them into the TxMetadata module and generalise
toShelleyMetadataHash to work over all ledger eras.

Will be needed for creating txs in later ledger eras.

Will be needed for making txs for later ledger eras.

Not yet generalised over ledger eras.

We would like the ProtocolParametersUpdate type to be able to be
converted both to and from the equivalent underlying ledger type. We
would like this for a couple reasons:
1. so that we can use this same type later for programs that analyse
   the blockchain and want to see the content of update proposals;
2. so we can switch UpdateProposal to use the representation of the
   surface API types, while still using the on-chain format for the
   binary serialisation. This requires converting in both directions.

We want to do 2. now because we want a single era-independent
representation for update proposals, and to convert into the
era-dependent ledger types on-demand when we make a transaction.

So we now have conversions in both directions.

Switch the UpdateProposal to use the representation of the surface API
types.

We stick to the existing on-chain binary serialisation format.

We want to do this now to add support for more ledger eras. We want a
single era-independent representation for update proposals, and to
convert into the era-dependent ledger types on-demand when we make a
transaction for a specific era.

The protocol params should always have been exported since it is a API
surface type. The UpdateProposal repreentation can now be public since
it now uses the API surface types too.

Use Text instead of URI. We will want to allow conversion in both
directions which means we cannot be more restrictive than the ledger's
validity rules.

We'll use this next to change the representation of certificates

We will switch the representation shortly and so these conversion
functions will become non-trivial.

This will make it easier to convert from a common era-independent type
into ledger era-dependent types.

We still use the same on-chain binary format.

Needed both directly and to be able to generalise other such
conversion functions.

Replace per-era instances with a single era-paramaterised instance.
This will be simpler as we add more eras.

Replace per-era instances with a single era-paramaterised instance.
This will be simpler as we add more eras.

Generalise over the IsShelleyBasedEra class.

The Allegra and Mary cases remain to do.

Switch from the Shelley.TxBody concrete type, to using the Ledger.TxBody
type family. The type family has different representations for different
eras.

For this step the specific era remains the same, so there are no other
changes. The next step will be to cover multiple eras, at which point we
will take advantage of the different tx body representations for each
era.

The 'ShelleyBasedEra' GADT tells us what era we are in.

The 'ShelleyLedgerEra' type family maps that to the era type from the
ledger lib.

The 'Ledger.TxBody' type family maps that to a specific tx body type,
which is different for each Shelley-based era.

Due to this use of GADTs We now need custom Eq and Show instances.

Do the minimal changes elsewhere, inserting error cases to fill in next.

This is partial in that we generalise the type, but the Allegra and Mary
cases are error TODOs for now. This is still helpful to allow downstream
code to type check at other eras.

All the Shelley-based eras are supported with one overloaded
implementation used at different types.

Still TODOs for validity intervals and minting.

We sort-of already had implementations of these in the impl of
to/fromShelleyAddress functions. Pull them out to top level functions
and put them next to the definition of the ScriptHash type.

We'll reuse these new functions in the next patch.

To/from the equivalent ledger library type. The ledger representation is
a pair of the lovelace value and a nested map of the non-ada assets.

Now that we have toMaryValue

Order the ada case first.

Move toByronLovelace to the Value module, and split the TxBody module
section on TxIn and TxOut so they're in separate sections.

We're about to add a bunch more sections for types used in the body.

Move the TxOutValue, MintValue and related functions from the Value
module to the TxBody module.

We're going to end up with a whole bunch of these era-dependent field
types for the tx body and it makes most sense to keep them all together
in one module.