[PATCH] ConnStateData flexible transport support

We are quickly approaching a time when a client connection can freely
migrate between protocols or versions of protocols. Already we have
ssl-bump which can switch a connection from HTTP to HTTPS. I am
expecting switching HTTP<->HTTPS via Upgrade, and HTTP/1<->HTTP/2 via
"magic", Upgrade, or ALPN.

Based on ssl-bump experience with switchedToHttps() and the pain that
can be predicted when there are several permutations of such accessors
to test against I am proposing the attached patch.

* Add a transportVersion member to ConnStateData which holds the current
protocol to be used over the clientConnection socket. This variable can
be altered whenever necessary to cause an on-wire protocol change. New
connections default to the protocol signalled in the http(s)_port directive.

* ssl-bump transforms the transportVersion from whatever it was
previously (usually HTTP or HTTPS) to HTTPS.
 - Also updated ssl-bump to set the traffic type flag tunnelSslBumped on
non-intercept traffic, which can be assumed to be a CONNECT request.

* transparent and reverse-proxy URL reconstruction is updated to use the
new member instead of the http(s)_port protocol= setting. This removes
edge conditions where the URL reconstructor needs to figure out ssl-bump
existence.

Christos,
 I would like some help with two ssl-bump related things if you have the
time spare:

 1) testing the new prepareTransparentURL reconstruction works on
ssl-bumped traffic.

 2) finding switchedToHttps() usage that can be replaced.
  When ssl-bump is operating we should now always have one of these
conditions being true:
   a) ConnStateData::port->flags.tunnelSslBump
   b) ConnStateData::port->intercepted() &&
        ConnStateData::transportVersion.protocol==AnyP::PROTO_HTTPS

The second one is low-priority even if this patch gets added. We will
find them later anyway as the code polishing progresses.

Amos