Convert CertState to a type family

[Lucsanszky]

Description

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
  
  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
  
  If you change the bounds 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)
• hie.yaml updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[lehins]

I did a quick skim over the PR and it looks awesome.
There is one important point that I made that will need to be address that has to do with a common issue of changes getting lost during rebasing, but that shouldn't be too hard.
I'll do a proper review once the PR is out of the Draft state.

[lehins]

For this PR this is totally fine, but just heads up for the future adjustments that we'll need to make we won't be able to construct it like that because VState will not be available.

This isn't really a problem since we can always construct it from an empty CertState, eg:

mkShelleyCertState pState dState = 
  def & certPStateL .~ pState
      & certDStateL .~ dState

mkConwayCertState pState dState vState = 
  mkConwayCertState pState dState & certVStateL .~ vState

Moreover in ledger rules we can always get away with modifying CertState, instead of constructing a new one.

Again, for this PR it will be fine to keep it as is, I am just giving you a heads up for the follow up work that we'll have to do.

[Lucsanszky]

Finally, this is now ready for review. I opted not to detail every little change in the changelogs but rather indicate the affected packages that CertState was converted to a type family.