Add more crypto provider flexibility

[bifurcation]

Right now, we support three different crypto providers: OpenSSL 1.1, OpenSSL 3, and BoringSSL. These providers have largely the same API, so we have a slightly hairy mess of #ifdefs to account for the differences. If we were to try to add support for CryptoKit, X-CUBE-CRYPTOLIB or liboqs, we would need things to look substantially different.

We should consider introducing a stronger interface/implementation separation, and segregating the implementation code according to the underlying crypto provider.

Prior art in mls-rs:

• https://docs.rs/mls-rs/latest/mls_rs/trait.CryptoProvider.html
• https://docs.rs/mls-rs/latest/mls_rs/trait.CipherSuiteProvider.html

Overall concept:

• lib/hpke/src has files for some set of providers
• Non-goal to allow runtime addition of new providers
• Each instance of MLSpp is built for a single, specific provider
• Consumer selects provider with CMake flags

[bifurcation]

I note that the approach in #424 effectively uses runtime dependency injection, so maybe it's not a bad idea to support runtime provider selection.