Improve key/suite/algorithm choice when creating VC/VP

## Background

It is very ambiguous exactly what key or algorithm will be used when creating a credential or presentation in Veramo 3.1 (&next).

Some keys can be used to sign using multiple algorithms / signature suites. For example, a Secp256k1 key can be used for: `ES256K`(jwt), `ES256K-R`(jwt), `EthereumEIP712Signature2021`(JSON), `EcdsaSecp256k1RecoverySignature2020`(JSON-LD), `EcdsaSecp256k1Signature 2019(JSON-LD)`, and a few others.

Some issuer DIDs have multiple keys that can be used for signing. If a new key is added specifically to sign new credentials, it won't automatically be used, especially if another managed key of the same type is found first.

## Proposal

I propose the following changes to the `createVerifiable*()` method arguments:

* `proofType` will describe the algorithm (e.g. `EdDSA`, `Ed25519Signature2018`), instead of `jwt`/`lds`/`712`
* `keyRef` will specify either the `id` of the verification method from the issuer DID document, or the internal `kid` known by `@veramo/key-manager`/`@veramo/did-manager`

The algorithm for creating proofs would change to:
* inspect the credential payload and extract the issuer DID
* first filter the keys associated with that DID by `keyRef`, if one is supplied,
* then filter the keys based on the matching `proofType`.
* If no key is left after filtering, throw an error.
* decide which plugin (jwt/ld/712) can generate the proof and call it with the filtered parameters.
* if an error is thrown by the called plugin and there are other keys/algorithms left after the filters, try the next one.

## Implications

* DID document of the issuer must be resolved when the `keyRef` does not refer to an internal key ID
* Since the implementations of JWT vs JSON-LD vs JSON proofs are provided by different plugins, the credential issuer plugin must also maintain a list of algorithms and their corresponding plugin implementation.
* Creating JSON-LD Presentations containing non LD credentials may fail because of LD reasons.
* The key metadata provided by `KMS` implementations becomes very important to decide if an algorithm or proof type is supported by a key. If this metadata is not available, some heuristics can be hardcoded, based on known key types.