createKey: make more generic and algorithm-driven

[mickrau]

@davidz25 To follow up on our conversation last week we would like to discuss making the createKey() function (a) more generic and (b) driven by the algorithm instead of the key features.

(a) generic
Currently, the base classes CreateKeySettings and KeyInfo are fixed to ECKeys. In the sense of crypto agility we would prefer to use more generic classes.

(b) algorithm-driven
Currently, the caller must specify the ecCurve parameter in the function createKey() and the algorithm parameter in the function sign().
In OpenID4VCI the wallet must create a new key based on the values in proof_signing_lag_values_supported contained in the issuer's metadata. We would like to create a new key with an algorithm identifier, instead of mapping algorithm id to curve parameters first. The use of a fully-specified algorithm identifier would also be more generic and not limited to EC in the future.

Please note that the algorithm identifiers currently used from the IANA COSE registry are not fully-specified. This specification creates fully-specified algorithm identifiers: https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-06.html