Create specialized newtype `VRFVerKeyHash`

[lehins]

Description

VRF algorithm should not appear in the hash, since that prevents us from changing the VRF algorithm. There is a potential we will do that in the future and switch to Batch VRF.

That being said, the biggest motivation behind this change is that we want to extract VRF and KES out of Crypto type class and having type signature like this

Crypto c => Hash (HASH c) (VerKeyVRF (VRF c))

prevents us from doing that.

Moreover, with addition of specialized role KeyRoleVRF to be used in VRFVerKeyHash (r :: KeyRoleVRF) c we gain type safety that prevents us mising up genesis and pool VRF key hashes.

Checklist

• [x] Commit sequence broadly makes sense and commits have useful messages
• [ ] New tests are added if needed and existing tests are updated
• [x] 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)
• [x] When applicable, versions are updated in .cabal and CHANGELOG.md files according to the versioning process.
• [x] 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)
• [x] Code is formatted with fourmolu (use scripts/fourmolize.sh)
• [x] Cabal files are formatted (use scripts/cabal-format.sh)
• [x] hie.yaml has been updated (use scripts/gen-hie.sh)
• [x] Self-reviewed the diff

[lehins]

I guess the changes related to the OverlayPredicateFailure shouldn't be mentioned in the corresponding CHANGELOG since we don't need to record predicate failure related changes, right?

This is actually not right. We do need to add changelog entries for changes to predicate failures. Moreover, in this case it is a breaking change and I totally forgot to bump the major version of the package and add a changelog entry for it. Thank you for spotting it