[PATCH] StoreID via eCAP and ICAP

Hello,

    The attached patch allows eCAP and ICAP services to set StoreID
values, just like many existing store_id_program helpers do. To avoid
surprises from rogue services, the optional behavior must be enabled in
squid.conf by adding "store-id=1" to the e/icap_service directive.
Adaptation services are executed before the StoreID helpers but they may
co-exist. The latest StoreID value wins.

The patch also merged eCAP and ICAP code that updates adaptation
history, resolving an old TODO.

Disclaimer: After these changes, options returned by broken eCAP
adapters that implemented adapter::Xaction::option() without also
implementing adapter::Xaction::visitEachOption() will stop working.
Similarly, options returned by broken eCAP adapters that implemented
visitEachOption() without also implementing option() may start working.
I do not think this is a big deal because the loss of backward
compatibility is limited to broken adapters that would have to be
rebuild for newer Squid/libecap anyway.

I used "Store-ID" for the name of the meta header (an ICAP response
header or an eCAP option name; not an HTTP header!). Other alternatives
considered but rejected:

Store-Id: Most registered MIME headers use -ID, not -Id.
http://www.iana.org/assignments/message-headers/message-headers.xhtml

X-Store-ID: Trying to avoid adding X-Store-ID now and then renaming it
to Store-ID ten years later, while adding more code for backward
compatibility reasons. The Store-ID header is not registered. I am not
going to write an Internet Draft to describe it, but somebody could try
to submit a _provisional_ Store-ID IANA registration that does not
require a Draft or an RFC AFAICT. However, the header would still need a
description on the web somewhere. Perhaps somebody can volunteer to take
a lead on that?

Archived-At: This is a registered header that is almost perfect for our
needs. The was worried that other developers would object to using a
completely different name compared to StoreID helpers (and the feature
name itself).

Content-ID: This is a registered header that may be reused for our
needs. However, StoreID is not restricted to (and typically does not
use) unique content identifiers, content checksums, etc. All StoreID
helpers I know map URLs and do not really know anything about the
corresponding response content. Archived-At reasoning above applies here
as well.

Any other reusable and registered (or at least "known") headers to consider?

I am happy to rename if a consensus builds around a different name,
including those above.

Thank you,

Alex.