Refactor Cryptosuites

[decentralgabe]

          Thanks. That makes sense to me now. 

The interface, as it stands, is promoting strong coupling across CryptoSuiteProofType and a signature algorithm (which is unclear in which interface it's defined). That makes it difficult to know what the expectations are when you're dealing with an implementation. Additionally, it's leaking implementation details because users will need to understand what implementation of the interface is being used.

I think the root cause of this is that CreateVerifyHash() is part of the CryptoSuiteProofType interface. Instead, what if there is a separate function with a parameter of
type CryptoSuiteProofType? If you need to specify whether the signing algo does digest within it, another method like IsSignDigested() bool to CryptoSuiteProofType. WDYT?

Originally posted by @andresuribe87 in #288 (comment)

[decentralgabe]

Ask is to refactor cryptosuites to all follow the form outlined by the Data Integrity specification. We should define a method on the interface to run the CVH and other algorithms in a generic manner, without needing to understand the specifics/internals of any cryptosuite

See: https://github.com/workdaycredentials/ledger-common/blob/master/proof/ld_signaturesuite.go#L36

[decentralgabe]

Much has changed; so we'll need to update the cryptosuite package to align with https://www.w3.org/TR/vc-data-integrity