delays are execessive (The varnish testdriver already has code to
deal with this)

The CLI commands in the file are executed before the worker
process is started, and the output is sent to stderr.

CLI failures (!= 200) are fatal, unless the command is prefixed
with a '-' in the file.

You can now do things like:

	$ cat I.file
	vcl.load vcl1 /foo/bar1.vcl
	vcl.load vcl2 /foo/bar2.vcl
	vcl.load vcl3 /foo/bar3.vcl
	start
	$ varnishd -f '' -I I.file -a :80 [...]

can stabilize test c00080.

Not doing anything for the -C case, since even FREE_OBJ was omitted. Do
we care since varnishd immediately exits once -C is done?

Refs #2232

When postponing,

- re-create the Expect header for pipe mode

- For synth content, close the connection by default, but allow
  VCL to veto this behavior

Prevent drain-reading the body if the connection is closed anyway
Respect Connection: close from vcl_synth

- when we already started reading the body
- for HTTP Versions less than 1.1

whichever comes first

Also log such resposenses

A case probably overlooked in d306f91c and something that needs some
pondering.

It begs a question: why didn't it fail?

Fixes #2203

It shares a lot of parsing infrastructure with log records, but doesn't
support the taglist syntax. Only a verbatim `vxid` token can be used as
the LHS, and only integer operators are supported.

	sub vcl_backend_response {
                return (pass(2s));
        }