Before this fix, Squid warned that "ALE missing HttpReply object",
because ALE::reply was initialized too late. This problem affected
both HTTP and FTP code paths.

With this change, it is now impossible to directly assign public
ALE::reply field. Another approach is to make this field private, but it
would require many out-of-scope changes.

... since FwdState::al may be nil sometimes and it is difficult to
predict whether these situations are possible in the two affected
places.

This is probably a safer way to handle locking/unlocking
of this member compared to the setReply() method.

This reverts commit 3461984.

* Fixed comments and documentation according to the wiki
  'response terminology'.

* Initialize http->al->reply just after clone(), in order to supply
  it to early ACLs checks called during building the final response
  header (e.g., reply_header_add ACLs).

After be6c958 ALE was supplied with 'sent' HttpReply, and many (but not
all) ACL checks could use it. Earlier directives, such as
adaptation_access and store_miss still lacked it. To resolve this, we
need ALE::reply to point to the reply available at the moment, starting
with the virgin reply.

Also fixed ALE::reply for all 1xx (control) messages. Though be6c958
adjusted it for control responses coming from the origin, it missed
self-generated control responses (force_request_body_continuation
directive).

cb36505 already covered many (but not all) similar cases.

When applying '<h' format code in Format::assemble(), two different
sources are used: ALE::headers::reply for all headers and ALE::reply for
specific headers. This unfortunate approach of storing one entity in two
different places caused problems with logging 1xx responses:
ALE::headers::reply remained uninitialized.

Also, even before this PR changes, the ALE::headers::reply string was
initialized too early with the adapted reply, while ALE::reply contained
the sent reply. Now these two fields are assigned synchronously.
However,  this does not protect from loosing synchronization when
ALE::reply is modified.

Also fixed '<h' to log headers without status line, which looks wrong:

* It does not correlate withe the similar '>h', which loggs just request
  headers

* Status code can/should be logged with a dedicated '<Hs' format code.

... thus addressing an XXX added at fdf6662. Instead of keeping the
string copy of the reply headers up-to-date (and risking loosing
synchronization on a modification) I think it is better to generate
it only when it is used.

Restored the old behavior for '<h', logging both statusline and headers.