!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.
Having read the rest of the PR I’d say that the introduction of such wrappers introduces complexity and maintenance overhead that is not justified by the gains. I very much prefer composition (of different things) over inheritance (shoe-horning different things into a common vehicle). What is returned from `Http.bind`, for example, is a `Source[IncomingConnection]` with some additional info, so why not make it a class that exposes both of these facts:
~~~scala
class HttpBinding(val source: Source[IncomingConnection],
                  key: Key { type MaterializedKey = Future[ServerBinding] } ) {
  def localAddress(map: MaterializedMap): Future[InetSocketAddress] = map.get(key).map(_.localAddress)
  def unbind(): Future[Unit] = map.get(key).map(_.unbind)
}
~~~
If we don’t want to expose the key, then we don’t have to. OTOH I don’t see a reason why we should actively hide it (i.e. I’d actually add one `val` keyword above). The Future can then also be failed if binding to the socket fails, for nice failure reporting.

The same argument holds for all uses of DelegateFlow: adding meta information via inheritance feels wrong to me, we should favor composition over inheritance. This keeps things clean and orthogonal, for example it removes the need to discuss what the return type of `IncomingConnectionSource.map(...)` shall be—this alone should demonstrate why I think the current proposal entangles things.