!htp #16162 Upgrade server- and client-side HTTP APIs to "final style"

This PR clears #16162.
It currently builds on #16383, so ignore Björn's commit in your review.

As a temporary measure I have added a stub TCP API as described by #16166. This `TempTcp` stuff will go away when #16166 is cleared.
> I am more confused by the existence of this method than by the joining operation. As a user, how would I decide if this is passive or not? What does passivity mean here?

The scaladoc states that a "passive server" scenario is one where the client initiates the conversation after the connection has been established. The doc on `activeFlow` describes an "active server" scenario as one where the server starts the communication after the client has connected.
What is unclear here? How can we improve these descriptions?

When you look at the HTTP API then `handleWith` is the only option for handling a connection, because a `Flow[HttpResponse, HttpRequest]` doesn't make any sense on the incoming side. We wouldn't want the user to see a `Flow[HttpResponse, HttpRequest]` that she is then "joining" with her own handler flow.
Rather, what I as a user want to do is handle all requests on a connection with the flow that I have written.
I find this quite clear.

Since there is value in keeping the APIs between HTTP and TCP consistent I'd argue for the inclusion of a `handleWith` functionality also on the TCP side, which works in exactly the same way as for HTTP.
The difference between TCP and HTTP (API-wise) is that on the TCP level you might also want to write an "active" server (certainly in a minority of cases). HTTP servers are always "passive".