Multi level transaction definition

[lehins]

Description

Added an additional type parameter to Tx and TxBody to allow implementing multi-level transactions in Dijkstra.

Checklist

• Commits in meaningful sequence and with useful messages.
• Tests added or updated when needed.
• CHANGELOG.md files updated for packages with externally visible changes.
  NOTE: New section is never added with the code changes. (See RELEASING.md).
• Versions updated in .cabal and CHANGELOG.md files when necessary, according to the
  versioning process.
• Version bounds in .cabal files updated when necessary.
  NOTE: If bounds change in a cabal file, that package itself must have a version increase. (See RELEASING.md).
• Code formatted (use scripts/fourmolize.sh).
• Cabal files formatted (use scripts/cabal-format.sh).
• CDDL files are up to date (use scripts/gen-cddl.sh)
• hie.yaml updated (use scripts/gen-hie.sh).
• Self-reviewed the diff.

[lehins]

Looks great! Awesome work, @Soupstraw!

[teodanciu]

Oh my god! This is a crazy PR! I reviewed until Alonzo, will do the rest tomorrow - sorry, my brain is hurting!
What's not clear to me is when to parameterize by the level type and when not , for example, ShelleyTx l era instead of ShelleyTx TopTx era, when defining instances (like: Show (ShelleyTx TopTx era)). Isn't it always gonna be ShelleyTx TopTx era ?
I understand for functions in rules, that they can get called with a different level parameter - but why is it useful for the types? Can we even have anything other than TopTx in ShelleyTx ?

Also mysterious I found that in some cases STxLevel l era ~ STxTopLevel l era was required to call mkSTxTopLevelM, and in others it seemed to know it.

I will look again tomorrow with fresh eyes and go through the rest of the changes.

[teodanciu]

Looks good (albeit most overwhelming) to me.
Just some more small suggestions that can be ignored and some questions.

I'm in awe at both of you for making these big and complex changes work 🙇