Simplify To/FromCBOR instances for DSIGN types

[lehins]

Description

I assume To/FromCBOR instance for DSIGN were not defined in the same "catch all" way as it is done for all other crypto types (i.e. the way it is defined in this PR) in order to prevent memory locked DSIGN implementation to have To/FromCBOR instances, because that would violate the safety guarantees of locked memory by leaking secrets onto the Haskell heap. However, now that we have a pretty solid memory locked DSIGN implementation we can safely provide those instances for all SigKeyDSIGN v, VerKeyDSIGN v and SigDSIGN v, because memory locked version will be a totally separate interface with type families named SigKeyDSIGNM v, VerKeyDSIGNM v and SigDSIGNM v. See IntersectMBO/cardano-base#255

Checklist

• Commit sequence broadly makes sense
• Commits have useful messages
• New tests are added if needed and existing tests are updated
• Any changes are noted in the changelog
• Code is formatted with fourmolu (which can be run with scripts/fourmolize.sh)
• Cabal files are formatted (which can be done with scripts/cabal-format.sh)
• Self-reviewed the diff

[JaredCorduan]

That all sounds reasonable to me, @lehins . I would feel better, though, for a stamp of approval from @iquerejeta or @dcoutts

[lehins]

Actually @tdammers will be a good person to double check this, since he is the one working on KES forgetting.

One way or another this PR is totally safe, because versioned CBOR is used only by the ledger and we do not deal with secret keys at all.