Store format of ETag in Squid

In order to be able to index the available ETag values for a given object Squid's normally flat object naming sheme needs to be extended with a per URL sub-index listing the available ETag values and their matching Vary information.

This is done by extending the "dummy" object introduced by Vary to also contain this index.

Format used is a text format with records of the following layout:

1. Key: <store key>
2. ETag: <ETag value>
3. VaryData: <vary header information>
4. VaryData: ...
5. ...

At this stage it is assumed that all objects share the same variance type. If multiple variances classes are to be supported then this can be done by extending the format with a Vary header field.

On updates the following information is available:

1. URL
2. method
3. new entity store key
4. ETag value
5. vary header data

Update algorithm:

Read in the old map one entry at a time, looking for suitable matches

1. on ETag match, update the key, and expire the old object if different
2. on Key, drop the old etag index data if ETag is different. It is not safe to inherit the variance after an object change.
3. on VaryData, remove the line if a different key. If this makes the record "empty" then expire the object from the store and remove it from the etag map
4. VaryData is added last in the Key record it corresponds to (after modifications above)

If no matching record is found for VaryData then add a new record with Key, ETag and VaryData.

Note: the above can be optimized slightly if it is expected there will be variance without ETag. However, HTTP/1.1 defines there SHOULD be a ETag on varying objects so let's not bother with that now.