Start to re-organize test hierarchy: ImpSpec

[lehins]

Description

This PR introduces a class base approach to enforcing common types of tests to be executed for all eras.

This approach also makes EraSpecificSpec unnecessary, since it further expands the same concept.

For now it only applies this approach to ImpSpec, but other will follow in subsequent PRs
Furthermore, it changes ImpSpec tests into consistent structure.

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.

[koslambrou]

How should we handle tests that are only applied starting from some era? For example, any plutus related tests should start from Alonzo. Should we have specialized typeclasses such as AlonzoBasedEraSpec which specialized functions like ledgerAlonzoBasedEraMain?

[lehins]

How should we handle tests that are only applied starting from some era? For example, any plutus related tests should start from Alonzo. Should we have specialized typeclasses such as AlonzoBasedEraSpec which specialized functions like ledgerAlonzoBasedEraMain?

This question can be answered only in specific context of what type of test it is. This PR, is only concerned with ImpSpec, organization for other types of tests is still coming. As far as your work in #5799, you should not be needing anything like this, because your PR is only suppose to be concerned with exampleTx.

[teodanciu]

Love it! Much easier to understand which tests get called, at a small price of a few lines repeated.

So the pattern seems to be: eraImpSpec implementations have:

• an "opt-in" part - the <Era>.<era>EraSpecificSpec ones, and an
• "auto-inheritable" part via Imp.spec - which is defined as the Imp.spec of the previous era plus the new stuff that is to be inherited in future eras.

Looks good to me, just a few minor remarks.