Should be able to set private key from secure handle

[huitema]

The currently supported method for creating a QUIC context read the private key in clear text from a file. This is convenient, but assumes that file system protections are sufficient to protect the private key. That's probably not true for all deployments.

The early version of picoquic supported a way to get the private key from memory, which is a bit better -- applications could for example read an encrypted file, decrypt it and set the key. This is discussed in issue #1585. The conclusion was that it would be better to pass the key as a "secure handle", as follow:

1- Application uses a secure process to load a private key, as enabled by crypto stacks like OpenSSL or MbedTLS.
2- Secure process does not expose the key bytes to the application but secure them, possibly in a secure enclave.
3- The crypto stack returns a "key handle" to the application.
4- The key handle is then used by the server to sign the TLS exchange and prove its identity.

The main problem with that design is that different crypto stacks use different type of handles. OpenSSL uses a pointer to "EVP_KEY". MbedTLS uses a pointer to "mbedtls_svc_key_id_t". (Minicrypto only supports a clear text setup.) We could design a generic API using a generic "void *" that would then be recast to the backend specific type, but this seems artificial, as the application would probably need a backend specific process to read the key. It seems preferable to adopt a three steps process:

1- Create a Quic context without specifying the key.
2- Let the application obtain a key handle using the application selected backend.
3- Load the key handle in the PTLS context.

We have a somewhat similar problem with certificates, with some applications asking to pass the server certificate as a memory blog rather than a PEM file.

Whatever we do, we need to document the solution, and also to add test verfying that the three step process works.