(Backport of 2bbcde1d with the fix b698aec2 squashed in)

doc fixes #2107

Updated error message in MGT_Child_Cli_Fail to indicate that we
actually have sent the kill signal to the child process.

A new jail level, JAIL_MASTER_KILL, is introduced. The mgt process
takes this level before killing the child process.

Fixes: #2010

A new function, kill_child() is introduced, so that kill() is only
called from this function. This is a preparation of fixing the jail
implementation.

There seems to be an error in the varnish jail design, which makes the
mgt process uable to kill the child process. To confirm this, add some
error checking to the relevant code.

Related to: #2010

This test wasn't working as it was supposed to, and would cause the
forward links graph building of log transactions to fail. The fail was
soft, as the reverse mapping still succeeded creating the right
mapping.

Depending on when the local thread log buffer was flushed, the problem
would show as spurious "duplicate link" log records to be inserted.

Fixes: #1830

Fixes #2017.

With a bit of documentation to explain how to use the two new macros.

Closes #2054

This file will now contain legacy macros, that is to say shims to deal
with older platforms and macros for out-of-tree VMODs introduced with
Varnish 4.0.0-tp1.

These macros work well but their interfaces aren't ideal and they leave
too much autotools work to downstream VMOD maintainers. They have also
suffered a lack of maintenance, like this 3yo comment:

    # Uses internal function for now..

New macros will be introduced, but the current macros are left as-is and
VMOD maintainers won't be forced to upgrade their build system.

A previous backport, "Use "none" to disable authentication" did not
skip mgt_cli_secret(S_arg) when -S '' was used. This fixes the
problem, so that -S '' has the same behavior as before.

Related to #2025.

thanks to @dridi for the dictionary lookup

Maybe it's just my brain that is incapable of considering the
fact that a bit of macro-fillin may in fact be #if 0 - disabled
here, so this should hopefully help me (and others?) to not
spend more life time than absolutely necessary on feeling stupid.

Spotted by: Dridi Boukelmoune

Thanks @nigoroll for the suggestion.

cost by correctly holding the mtx while examining it.

Acquiring a read lock on the CLI thread is unnecessary since a write
lock may only be acquired on that very thread.

The locking order when both are required is:

    (struct vcl).temp_rwl => vcl_mtx

Fixes #2008

Conflicts:
	bin/varnishd/cache/cache_vcl.c

There is currently no locking around temperature changes despite the
fact that it may be read outside of the CLI thread to make decisions.

In the case of a panic, instead of locking we simply make sure not to
perform an incomplete read of the pointer.

Conflicts:
	bin/varnishd/cache/cache_vcl.c