eCAP: (A) Support optional adapter parameters and (B) fix virgin body handling.

eCAP: (A) Support optional adapter parameters and (B) fix virgin body handling.

(A): Optional adapter-specific eCAP service parameters can be specified after
the Squid-recognized ones:

    ecap_service s1 respmod_precache ecap://...  name1=value1 name2=...

These extra parameters are passed as (name, opaque value) pairs to the
adapter, using the newly added libecap::Config API. Adapters should throw if
they cannot understand the parameters to protect users from typos in optional
Squid-recognized parameters.

Squid-recognized service parameters can also be passed to adapters. Adapters
can distinguish them from custom ones or typos because their names have host
IDs set. We currently only pass one Squid recognized service parameter called
"bypassable", with a boolean values of "1" or "0". This tells Adapter whether
Squid can try to bypass the adapter in case of problems. In our experience,
many real adapters benefit from such knowledge because they can be less strict
and more forgiving if Squid might ignore their decisions anyway.

To support optional adapter parameters for eCAP without bothering ICAP,
we now allow ICAP and eCAP to create protocol-specific configuration objects.
ICAP code uses old defaults. eCAP implements parsing of optional adapter
parameters and sharing them with adapters

As a side effect, service configuration objects are now refcounted and each
service (once created) is responsible for its config. The global collection of
configs is emptied once the services are created.

(B) eCAP transaction wrapper code (Ecap::XactionRep) failed to pass a few test
cases when dealing with virgin bodies. The code used complex state and
mishandled several proxyingVb, nil body_pipe, and stillConsuming value
combinations. proxyingVb was especially troubling because it was not clear
whether it refers to us receiving vb from Squid core or sending vb to the
adapter. The two states are related but different because we could be
receiving vb from core but not sending it to the adapter and vice versa.

I have removed proxyingVb completely as the body pipe state alone is
sufficient to understand our dealings with Squid core. I added makingVb to
track adapter vb needs.

Also improved Ecap::XactionRep status debugging.