[PATCH] experiment in private caching

This patch seeks to reduce the constant MISS situation we have from
false failures doing Host: header verify.

The concept is that for certain requests we have an additional piece
added to the cache key, HttpRequest::storeSecurityKey.

 * when looking up a StoreEntry to be a HIT we check for the "normal"
URL or Store-ID based key first.

 * when no StoreEntry can be found for the "normal" entry, we lookup a
key with the additional piece.

Using the original dst-IP as an optional key extension for requests
suspected of Host forgery will allow groups of clients to HIT on the
same suspected forged response if they all happen to get the same IP for
the server. Such clients would have been passed-thru to the same server
anyway and get back whatever result it provides, valid or hijacked.

The expected behaviour by Squid for the troublesome servers is the same
as if they were emitting broken Vary: header. Squid will cache a variant
for each destination IP that fails verification, with a mix of HIT/MISS,
until one suddenly passes and all traffic becomes HITs on the
non-varying entry.

NOTE: due to my sparse level of knowledge about the store API complexity
I am needing help testing that the patch attached actually does the
above behaviour.
 Specifically that it does not cache one of the suspect objects in a way
that leaves it able to be HIT on without the dst-IP security key.

Amos