This will make the service work out of the box by a simple
``systemctl enable varnishncsa``, as using the pidfile requires
``/var/run/varnishncsa`` to be created.

This is in line with the ``varnish.service`` anyway.

Due to https://github.com/varnishcache/varnish-cache/issues/2316
we cannot reliably config-test the VCL in the init-script.
If users want to configtest the VCL in advance of a restart, this
can be done with loading the new VCL into the running varnish, or
running ``varnishd -C`` with a different option-set that will not
conflict with the running instance(s).

And make it possible to reload several labels in a short time. Make sure
the date is always UTC.

Revert back to the old dirty read trick.

According to the manual it should be possible to use the {n} notation in
regular expressions but for some reason it doesn't work here.

This reverts commit b8a0ea97.

I'm not convinced that we want to prevent reloaded VCLs to cool down
after subsequent reloads.

Otherwise the warmup delay might be ineffective.

Introduce a -h option for a usage more discoverable.

After feedback from @ssm.

The output of vcl.discard is ignored because it's a blank line, so
instead the script forges a message. In case of failure, the error
message is still displayed.

Confirmed by testing the behavior of various varnish versions.

If a VCL was reloaded at the date of this commit, it would change from:

    reload_20170321T174643

to

    reload_20170321_174643

This gives second resolution to the reload's name but keeps the name
compact, parseable, and naturally sorted. An example is displayed with
the usage error message.

It was there to test a failure...