Mirage smaller interface

#211 reminded me that we have a completely non-working [stub](https://github.com/mirleft/ocaml-tls/blob/cfaaed1bfaf4e9c806caf4463d77a130980ae8c5/mirage/tls_mirage.ml#L180) for a `V1_LWT.TCPV4`.

We originally required `TCPV4` to get `close`. `FLOW` has since gotten that function, and as all we need is `read`, `write` and `close`, we can accept that instead of tcp. We should be able to speak TLS over any transport this way.

On the other side (of the arrow), we used to produce something like a `FLOW` using the `Make` functor, and a completely stubbed `TCPV4` with the mis-named `Make_flow`. This was provided mostly to expose `close`, but with the changing `TCP` signatures, I think we'd better stop pretending that we actually implement one.

So I moved our core mirage functor from `TCPV4 -> TCPV4` to `FLOW -> FLOW`. It means we had to stop piggybacking on `TCPV4.error` (`Other of string`), so we get separate error descriptions for our layer and the layer below, which should come in handy if we expand the error reporting from the raw TLS alerts into something more usable. And we can drop the fake `TCP` implementation so we can stop breaking when this, basically unrelated, interface changes.

Caveat: `example2` is still broken. We should probably integrate into `conduit` on mirage side too, because `HTTP.Make` now consumes a `Conduit_mirage.S`. But this would create a circular dep tls/example2->conduit->tls, and I don't see a way to synthesize a `Conduit` from outside, using just a `FLOW`. Maybe @avsm knows how to create it?