Ts newstyle specs

[TimSheard]

Use the new style constrained generators to build Specifications of well formed type used in the Cardano Ledger.
Well formed means that constraints that should hold in the NewEpochState on the chain will hold on the randomly generated
values. The (WellFormed t) class has a has a member function with type ( wff :: Gen t )

These Specifications will probably have to be refined over time. But they are complete in that the machinery exists for every
type in the Ledger. Currently they mimic the constraints in the oldstyle constrained generators. They are significantly simpler and much more composeable.

The PR also has a few fixes that were necessary to handle the constraints we wrote. This PR exercised the constrained generators library quite a bit, and it needed some additions. These include

• Filled in missing cases in computation of cardinality, methods cardinalTypeSpec and cardinalTrueSpec
• Better use of constraints like (x ==. mempty) to get accurate size information
• Added typeSpecOpt to a few HasSpec instances
• Added the function rngSet_ :: Term fn (Map a b) -> Term (Set b)

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages. New section is never added with the code changes. (See RELEASING.md)
• Code is formatted with fourmolu (use scripts/fourmolize.sh)
• Cabal files are formatted (use scripts/cabal-format.sh)
• hie.yaml has been updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[MaximilianAlgehed]

@TimSheard may I suggest - to make the rngSet_ thing easier to implement - that you rebase this on #4325 and add a TestableFn for rngSetFn? That way you'd get a lot more certainty about the implementation.

Another thing I've been thinking about is it it wouldn't be better to just bite the bullet and implement toSet_ :: Term fn [a] -> Term fn (Set a) instead of special casing it for the range of maps?

[TimSheard]

So my experience with maps suggests a solution for List. We can add that later.

[MaximilianAlgehed]

I haven't had time to look at the new style generators for maps in detail yet, but I trust that once we run enough tests we'll be quite sure they work correctly enough. It's important that we don't reduce the number of tests we run here because this is very tricky territory.

[lehins]

Closing in favor of #4575