[DO NOT MERGE] Rename CDDL fields to better reflect their origin and be more reusable

[aniketd]

NOTE

This is deprecated in favour of potentially several new ones.

Description

This addresses the initial part of #5194 .

1. Switch from exporting everything and hiding in the new era to exporting just the reusable parts and import the whole module in the new era.
2. Move some more field definitions into core and reuse them.
3. Name every field that is new in an era prefixed by that era-name.

Follow-up PRs would be to actually address the heart of #5194 to reduce duplication to a minimum.

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.

[neilmayhew]

Apart from the potential irregularity I commented on, this refactoring seems like it should make no difference to the CDDL.

Perhaps the test failures are due to the issue I pointed out?

[teodanciu]

I had a first pass and left some comments.
In addition, I'm also wondering if it's beneficial to remove the distinction between the types in cddl that represent hashes vs just bytes (so the replacement of hash32 with bytes32).
Even though they boil down to the same thing, it might bring some value to distinguish them? What do you think?

[lehins]

I only took a quick look at this PR. I'll do a more thorough review tomorrow.