TLS tunnel over Lwt_io.channel

[art-w]

I'm marking this PR as a draft, because it exposes the functionalities of TLS-over-TLS added by this PR mirleft/ocaml-tls#499 which hasn't yet been reviewed... but I have some questions on how to best present this feature in Conduit :)

For context, @MisterDA has a working implementation of cohttp-lwt-unix client requests with http/https proxying, which relies on conduit-lwt-unix for TLS and on this PR for the "https over http(s)", which happens because https proxies provide a safe tunnel for the client to negotiate the TLS connection with the server. For this to work though, we need to able to reuse an existing connection instead of having Conduit create a new socket. The mirleft/ocaml-tls#499 PR has more details on how this works, but I've also added an example in Conduit to test the flow if you are curious.

[hannesm]

What state is this in? Is there anyone interested in conduit reviewing feature PRs? I still don't understand conduits purpose, and only do maintenance (mainly because I want to release mirage) ;)

[art-w]

I've rebased and removed the draft status, since the tls dependency has since been released :)
The feature has been thoroughly tested with mirage/ocaml-cohttp#1080 so I think it's in good shape, although it would be nice to have a conduit expert opinion on the endp_of_flow question.

[art-w]

I went with exposing the TLS tunneling over an existing Lwt_io.channel connection by exposing a new type Conduit_lwt_unix.endp which extends Conduit.endp with the Lwt-specific feature, as this seemed like the most natural solution... @samoht Would you have some time to look at this PR? :)

[samoht]

LGTM