Add GeneratingCONNECT step for the existing at_step ACL (#484)

Add GeneratingCONNECT step for the existing at_step ACL (#484)

The new step allows admins to customize CONNECT request generation using
request_header_access and request_header_replace. As detailed below,
matching the request method does not work for those purposes.

request_header_access controls what HTTP request headers Squid _sends_.
However, this directive, like most other ACL-driven Squid directives,
uses the received request, _not_ the being-formed to-be-sent request.
This can be confusing, but it is the correct design/behavior.

When Squid is about to send a CONNECT request to a cache peer, what
_received_ request should request_header_access ACLs look at? There are
several ways to answer that question:

1. The received CONNECT request (or, for intercepted TLS connections,
   its faked equivalent). This is how the current CONNECT-sending code
   works when establishing the tunnel for a not-yet-bumped client
   connection. Problems:

    1. The CONNECT request received by Squid was not meant for the cache
       peer. It was meant specifically for this Squid. While it may have
       info useful for request_header_access checks, it is conceptually
       wrong to think of whats happening as "forwarding of that received
       CONNECT to the cache peer". Unlike GET requests, the CONNECT
       request that this Squid will send to the cache peer is dedicated
       to the Squid-peer connection. It is generated, not forwarded.

    2. That CONNECT request may have been received a long time ago, and
       Squid may have forwarded many bumped GET requests since then. It
       feels strange to consult such an old/"disconnected" message.
2. The received (and bumped) GET request. This is how the current
   CONNECT-sending code works when establishing the tunnel for an
   already bumped client connection. Problem:

    1. Squid is about to send a generated CONNECT request, not to
       forward a received GET request (the latter will happen later,
       after the CONNECT transaction). The two requests may differ a
       lot. Using a GET request when generating a CONNECT request is
       confusing: "Why is my CONNECT method ACL does not match when
       Squid sends a CONNECT request?!"

3. No request. Problems:

    1. Some old configurations that use request-specific ACLs with
       request_header_access will generate runtime "missing request"
       warnings and may fail to work correctly.

    2. Extra admin work is required to store request-specific
       information as connection annotations that request_header_access
       ACLs can still access.

    3. Conceptually, there is a request that Squid is establishing this
       CONNECT tunnel for. Squid will access-log that request. Hiding
       that information from ACLs feels odd/wrong. And some of that info
       would still be accessible to ACLs (via ALE/etc.). This hiding
       does not really hide all of the details.

Our solution preserves what received request Squid is looking at. Items
1 and 2 above still apply (depending on the configuration and on the
request being processed), with their unique problems intact. Those
problems are not as bad as the problems associated with the item 3!

The at_step ACL was added for SslBump but, IIRC, we knew that it may
eventually cover other request processing steps. Generating a CONNECT
request is one of those other steps.

This is a Measurement Factory project.