WIP: Preliminary ghc 9.14 support

[erikd]

Description

Preliminary ghc 9.14 support

• Hopefully https://gitlab.haskell.org/ghc/ghc/-/issues/26381 will be resolved before the final 9.14.1 release.

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.

[erikd]

I ran scripts/fourmolize.sh and it changed the formating of a bunch of stuff that I had not touched and seemingly does not handle the CPP I needed to get this compiling.

I ran scripts/gen-hie.sh but all it did was delete the entire contents of the hie.yaml file.

[lehins]

I looked at the PR and got really scared by all CPP in it.
We ought to resort to CPP only when we absolutely have to. In this case it doesn't look like it is the case, hence I left a couple of comments with suggestions on how we can get rid of them.

[lehins]

Instead of adding CPP all over the place for this, it is better to disable the warning -fno-warn-redundant-constraints in cabal.project file for ghc-9.14

This incompatibility will result in a mere warning, not a build failure. Since ghc-9.14 is not going to be a default compiler for some time, we don't need to add all this ugliness just to get rid of a warning. Once we decide to switch to ghc-9.14, all we'll need to do is just remove the redundant constraints and we'll be done with it.

[lehins]

@erikd Could you please tell me why would we add 1K lines of CPP code for new data syntax where pattern keyword still works fine? Please revert all those changes so we don't have to suffer each time we deal with pattern synonyms

Suggested change

	#if __GLASGOW_HASKELL__ >= 914
	data SpendingPurpose,
	data MintingPurpose,
	data CertifyingPurpose,
	data RewardingPurpose,
	#else
	pattern SpendingPurpose,
	pattern MintingPurpose,
	pattern CertifyingPurpose,
	pattern RewardingPurpose,
	#endif
	pattern SpendingPurpose,
	pattern MintingPurpose,
	pattern CertifyingPurpose,
	pattern RewardingPurpose,