Bug #1819 fix in three parts: Retry failed ICAP pconns.

    Bug #1819 fix in three parts: Retry failed ICAP pconns.

	Bug #1819 fix, part 1: simplify ICAPInitiator-ICAPXaction link.
	Part 1 changes should have no effect on Squid functionality.

	To retry failing persistent ICAP connections we may need to
	start more than one ICAP transaction for a given HTTP message.
	This needs to be done somewhere between ICAPInitiator and
	ICAPXaction so that neither is affected much. The design will
	be similar to HTTP FwdState.

	This change reduces ICAPInitiator dependency on ICAPXaction so
	that it is easier to insert transaction retrying logic/code
	between them. It should have no effect on Squid functionality.

	HTTP client and server (both ICAPInitiators) used to keep a
	Pointer to ICAP transaction and extracted adapted headers from
	the finished transaction using that Pointer (which forced
	ICAPModXact to use a self-Pointer).  ICAP service
	representative used custom callbacks to receive new options
	from ICAPOptXact.

	Now, all ICAP initiators use the same asynchronous
	message-based API to communicate with ICAP transactions they
	initiate. On the core side, the API is defined by
	ICAPInitiator, as before. On the ICAP side, the API is defined
	by the newly added ICAPInitiate class. The latter will also be
	used as a base for ICAPLauncher, the future ICAP transaction
	retrying class.

	Bug #1819 fix, part 2: retry the ICAP transaction when its
	pconn fails. Part 2 changes should enable Squid to handle race
	conditions of ICAP pconns.

	HTTP client, server, and ICAP server representative (all
	ICAPInitiators) used to start ICAP transactions. If a
	transaction fails due to a persistent connection race
	condition, the initiator would either terminate the HTTP
	transaction or bypass the ICAP failure, violating the protocol.

	Now, instead of starting an ICAP transaction directly, the
	above initiators start ICAP Launcher. The Launcher starts the
	ICAP transaction and retries it (i.e., starts another
	transaction with the same set of parameters) if needed. The
	Launcher is both ICAP initiator (because it starts ICAP
	transactions) and ICAP initiate (because it is started by other
	ICAP initiators). The launcher proxies ICAP communication
	(usually one or two messages each way) and makes retries
	transparent to initiators.

	All ICAP transactions corresponding to the same adaptation of
	an HTTP message are sometimes referred to as a single ICAP
	query.

	An ICAP transaction can be retried until it read data from the
	ICAP server or consumed virgin body. This means that a ICAP
	transaction may go as far as writing the entire ICAP Preview
	before aborting in a retriable state. When retrying, persistent
	connections are not used. If the first retry fails, the query
	fails. Thus, a query cannot contain more than two transactions.

	Two new things were added to support ICAPLauncher:

	First, AsyncJob, is a class that handles the basic logic of
	maintaining an asynchronous job or task such as an ICAP
	transaction or a launcher. All core AsyncJob functionality was
	moved from ICAPXaction and ICAPModXact classes. We could not
	use the two classes for the launcher because ICAPLauncher is
	not a transaction.  While currently specific to ICAP, this
	object may eventually be moved to Squid core and serve as a
	base for other asynchronous jobs or logical threads.

	Second, a temporary hack was added to support cbdata operations
	by two parents of a single CBDATA class (ICAPLauncher is both
	ICAP Initiator and Initiate). The second parent (ICAPInitiator)
	defines toCbdata() method that ICAPLauncher overwrites to
	provide a usable cbdata pointer to code that only sees an
	ICAPInitiator pointer. The ICAPInitiator pointer is unusable
	for cbdata when it comes from the middle of the ICAPLauncher
	object. Also, the initiator pointer is stored along with its
	cbdata so that the latter can be accessed (and unlocked) even
	if the initiator object is already deleted. These hacks will
	disappear once cbdata becomes object-aware.

	Bug #1819 fix, part 3: do not reuse a pconn when we may fail to
	retry it. Part 3 changes ensure that the HTTP message body is
	backed up when reusing a persistent connection (until we know
	there are no race conditions). They also disable pconns when we
	cannot backup enough.

	Decide on preview before connecting to the ICAP server because
	if we are doing preview, we can retry a failed pconn even if we
	cannot backup the entire body. Renamed shouldPreview() to
	decideOnPreview() and made the call less dependent on the
	context.

	Disable transaction retries if we are not using a persistent
	connection. ICAP does not talk about retrying failures other
	than pconn race conditions.

	It might be OK to retry other failures, but I have not done the
	required analysis and am not going to do that in the
	foreseeable future. For example, other failures may need other
	conditions for disabling retries (current code should disable
	retries when the first response byte is read).