Hybrid KEM: more combiners, more abstraction

[bhess]

Follow-up after #16:

• So far, the shared secret uses "Comb-Concat" as described in https://tools.ietf.org/html/draft-ietf-tls-hybrid-design-01#appendix-B.4.1. The same is done in OSSL111. This is suitable for inputting the shared secret to the TLS 1.3 key schedule. Compared to the implementation in OSSL111, the oqs-provider can also be used outside a TLS context. For this purpose, a method like "Comb-KDF" would be useful.
• Investigate using more OSSL3 API to allow more flexible combination of hybrid schemes: -> query algorithm parameters (secret-, ciphertext-, key-lengths) with provider API -> define individual algorithms for hybrid KEM in an array -> unify initialization of EVP-ECP and EVP-ECX code

[mouse07410]

IMHO, from practical point of view, a construct like

K = KDF (SS1 || SS2 || ... || SSn)

is hard to beat, both security-wise and simplicity-wise. I don't think we need anything more elaborated, though a few details should be written down, like fixed length of each shared secret.