Refactoring HTTP/2 connection init.

[tomchristie]

Our HTTP/2 connection init currently sends the initial outgoing settings frame, and then continues.
Incoming settings frames are handled whenever we read data.

This leads to a bit of awkwardness around our max-streams-semaphore handling. See #738 and #757.

A much neater approach would be to have the connection init lock until both the initial outgoing settings frame has been sent and the initial incoming settings frame has been received. See https://httpwg.org/specs/rfc7540.html#ConnectionHeader

This way we can instantiate the max-streams-semaphore correctly up front, don't need weird wrangling of it at the point of init, and don't need cancellable async operations at the point we set it up.

(I'm aware that I'm not phrasing this all that clearly, but the upshot here is - it would make sense for the connection init to handle both sides of the initial handshake and ought to lead to a more obvious flow of control through the HTTP/2 code)