Title: Support for BoringSSL asynchronous private key operations

Description:
BoringSSL has support for asynchronous private key operations [1]. The operations can be used for TLS signing and decryption. It would be nice to have Envoy support the asynchronous operations by implementing an private key extension API. An extension implementing the API could be registered for a TLS context. There has been discussion regarding this at envoy-dev mailing list, and I think this is the preferred approach.

My use case for this functionality would be TLS hardware acceleration (using Intel QuickAssist Technology), but other use cases exist, such as having keys in separate hardware or network service.

I would like to have a try at implementing this, if this is something that might be of interest. I'm opening this issue for suggestions and comments before going for the implementation. :-) My current prototype of the BoringSSL private key support in Envoy suggests that at least the following functionality is needed:

1. In the new API, have a function for finding out if the current TLS context should be handled asynchronously or not (call the extension with TL parameters). For example, not all ciphers can be accelerated.
2. Create a ssl_socket.cc callback to make it possible to call TLS functions (SSL_do_handshake()) again when the async operation has finished in the extension.
3. Add plumbing to let the private key extension to add callbacks to the thread event loop.

Relevant Links:
[1]: https://github.com/google/boringssl/blob/master/PORTING.md#asynchronous-and-opaque-private-keys

CC @PiotrSikora @htuch