refactor(http/upgrade): remove HttpConnect extension

[cratelyn]

this branch is motivated by review feedback from #3504. see
linkerd/linkerd2#8733 for more information on upgrading hyper. there,
we asked:

I wonder if we should be a little more defensive about cloning [HttpConnect]. What does cloning it mean? When handling a CONNECT request, we can't clone the request, really. (Technically, we can't clone the body, but practically, it means we can't clone the request). Can we easily track whether this was accidentally cloned (i.e. with a custom Clone impl or Arc or some such) and validate at runtime (i.e., in proxy::http::h1) that everything is copacetic?

linkerd-http-upgrade provides a HttpConnect type that is intended
for use as a response extension. this commit performs a refactor,
removing this type.

we use this extension in a single piece of tower middleware. typically,
these sorts of extensions are intended for e.g. passing state between
distinct layers of tower middleware, or otherwise facilitating
extensions to the HTTP family of protocols.

this extension is only constructed and subsequently referenced within a
single file, in the linkerd_proxy_http::http::h1::Client. we can
perform the same task by using the is_http_connect boolean we use to
conditionally insert this extension.

then, this branch removes a helper function for a computation whose
amortization is no longer as helpful. now that we are passing
is_http_connect down into this function, we are no longer inspecting
the response's extensions. because of that, the only work to do is to
check the status code, which is a very cheap comparison.

this also restates an if version != HTTP_11 { .. } conditional block as
a match statement. this is a code motion change, none of the inner blocks
are changed.

reviewers are encouraged to examine this branch commit-by-commit; because
of the sensitivity of this change, this refactor is performed in small,
methodical changes.

[cratelyn]

for posterity, i've run the linkerd/linkerd2 test suite against this branch, as of linkerd/linkerd2@57dd7f4.

[cratelyn]

for posterity, this is also related to #3540.