fix(http2): fix internals of HTTP/2 CONNECT upgrades

[seanmonstar]

This refactors the way hyper handles HTTP/2 CONNECT / Extended CONNECT. Before, an uninhabited enum was used to try to prevent sending of the Buf type once the STREAM had been upgraded. However, the way it was originally written was incorrect, and will eventually have compilation issues.

The change here is to spawn an extra task and use a channel to bridge the IO operations of the Upgraded object to be Cursor buffers in the new task.

ref: rust-lang/rust#147588
Closes #3966

BREAKING CHANGE: The HTTP/2 client connection no longer allows an executor that can not spawn itself.

This was an oversight originally. The client connection will now include spawning a future that keeps a copy of the executor to spawn other futures. Thus, if it is !Send, it needs to spawn !Send futures. The likelihood of executors that match the previously allowed behavior should be very remote.

There is also technically a semver break in here, which is that the Http2ClientConnExec trait no longer dyn-compatible, because it now expects to be Clone. This should not break usage of the conn builder, because it already separately had E: Clone bounds. If someone were using dyn Http2ClientConnExec, that will break. However, there is no purpose for doing so, and it is not usable otherwise, since the trait only exists to propagate bounds into hyper. Thus, the breakage should not affect anyone.

[seanmonstar]

@nox you originally implemented this, I presume because you needed it in an application. Would you be able to take a look, or even try the branch in your app?