Introduce an asymmetric_common module

[jedisct1]

Signatures used to have their own key types: signature_keypair and signature_publickey

With a bunch of associated functions such as signature_keypair_import().

This changes these to generic keypair and publickey types, with generic functions over these, that can be shared by signatures and key exchange mechanisms.

So,

signature_keypair_generate("Ed25519", None) returning a SignatureKeyPair

becomes

keypair_generate(AlgorithmType::Signatures, "Ed25519", None) returning a KeyPair

The exact same type and function can be used to create a key pair for non-signature purposes:

keypair_generate(AlgorithmType::KEM, "ntruhrss701", None)

This makes the API surface smaller compared to using specialized types and functions. The downside is that it makes static type checking more difficult.

In addition to an algorithm name, we also now need to provide an algorithm type (and the enum we had for options can be reused).

Without this, a SignatureKeyPair::create(alg_name) function exposed by a library could be used to create a different type of key pair. Signature operations would eventually fail, but the API should prevent the inconsistency at key creation time.

Besides the key exchange API, a motivation for this change is the fact that once finite field arithmetic operations are available, a common requirement will be to convert the output of these operations directly into keys.

We may also want to be able to perform conversion between compatible keys (for example between X25519 and Ed25519).

Having specialized key types and functions for these operations would enlarge the API surface even further.

From a bindings perspective, the generic types can be implemented as internal classes, with user-facing classes being derived from these.

For example the AssemblyScript bindings still expose SignaturePublicKey and SignatureKeyPair classes, but these classes just extend PublicKey and KeyPair with sign and signature_verify() functions.

In language supporting generics, generics can also be used to add compile-time type safety as an option to dedicated types and functions.

[jedisct1]

Merging this, mainly to update the implementation since breaking changes happened in the wasmtime world. But we may want to go back to specialized types later, especially once tooling improves to make it easier to define structured interfaces.