Ensure we have a reliable embedded TLS client backed by libcrux for the demo

[keks]

Work has started on a libcrux provider for Rustls: https://github.com/cryspen/rustls/tree/keks/libcrux-provider

While Rustls, when using our provider, can fetch a small file off github, it runs into various error conditions on most websites (e.g. google.com). However, it's not entirely clear if this is a bug in Rustls or in our provider; When running the test client backed by the example provider, it also failed to GET google.com - but with a different error. I think the current options are:

• The example provider is doing something wrong and we copied it
• We are doing something wrong with an error of our own making
• Rustls is doing something wrong

One more thing: I changed the provider tests to also include libcrux, and that makes it run the HPKE tests between all permutations of pairs of implementations, and we fail one of these permutations, one of the implementations can't decrypt our ciphertext, but the other can. I doubt that it is related to the above though, because that likely doesn't even use HPKE. Also, this might also be an issue in the other implementation.

Some other info so we can quickly start working on this again:

• Run test client with libcrux provider: cargo run -p rustls-libcrux-provider --example client

• Run test client with example provider: cargo run -p rustls-provider-example --example client`

• Run provider tests: cargo run -p rustls-provider-test

• [no_std] compatibility for standalone crates libcrux#313

• [Feature request] no_std support bertie#126