!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.
Maybe I’m a little thick (and maybe that’s what Endre means) but I don’t get the difference between an active and a passive server. I can use `handleWith` and still have the server be the first one to speak on this connection, or am I missing something? This means that `handleWith` is nothing but a very small convenience wrapper around joining something to the `activeFlow`. It would maybe help if someone pointed out a case where the implementation of `handleWith` would want to do something else. If that case does not exist then I’d vote for removing this method.
~~~scala
conn.handleWith(myHandler)
// versus
myHandler <~> conn.activeFlow run ()
// or
myHandler.join(activeFlow).run()
~~~
I agree with Endre that we want users to immerse themselves in a world of streams, and having just one universal way of doing things will help a lot. I am fully with you on the convenience accessors instead of using Keys in the ServerBinding, but setting up and running streams should be explicit, with the exception of “closed” DSLs like
~~~scala
Http.bind(...).handleWith(myRoute)
~~~
The difference here is that this form does not mesh with other stream parts, it is standalone and serves exactly one specific use-case. TCP streams are not that narrow in their applicability.