Partially addresses #2846. I've avoided mentioning NULL on purpose as
it's not really meaningful nor accessible from VCL. ymmv.

Pedantic back-port note: those are acronyms.

Add tests for vcl_keep and move vmod_so_keep together.
Reported and diagnosed by jw @ irc.

Enabled when using varnishtest -L.

this would have caught 7395ecae

Other polish.

$Module description, and suggest people to do it that way.

Make reporting syntax errors easier.

This adds rate limiting to varnishncsa and varnishlog.

Rate limiting is done on a per-transaction basis, respective to the
grouping mode selected. I.e. for -g request the limit will apply on a
per-request basis, -g raw on a per-record basis, etc.

Rate limit is specified as -R <limit>[/duration]. Default period if not
specified is seconds ('s').

This adds a ctx->handling test at the beginning of any compound
statement, to catch the cases where VRT_fail was invoked as part of an
if test condition.

Fixes: #2840

This may break out of tree code not respecting include order of vdef.h
first (or via cache/cache.h). It's trivial to fix and forces consumers
to follow the tracks.

Refs #2791

Seen once, and failed to reprocuce (yet), needs to be understood
better

from vmod_blobdigest tests/usage.vtc:

**** v1    1.8 CLI RX|No panic to clear
***  v1    1.8 debug|Info: manager stopping child
***  v1    1.8 debug|Debug: Stopping Child
**** v1    1.9 vsl|          0 CLI             - EOF on CLI connection, worker stops
***  v1    2.8 debug|Info: Child (174227) ended
***  v1    2.8 debug|Info: Child (174227) said Child dies
***  v1    2.8 debug|Debug: Child cleanup complete
***  v1    2.8 debug|Assert error in MCH_TrackHighFd(), mgt/mgt_child.c line 203:
***  v1    2.8 debug|  Condition(fd > 0) not true.
**** v1    2.9 STDOUT poll 0x10
**   v1    2.9 WAIT4 pid=174215 status=0x0086 (user 0.914949 sys 0.567445)
*    v1    2.9 Expected exit: 0x0 signal: 0 core: 0
---- v1    2.9 Bad exit status: 0x0086 exit 0x0 signal 6 core 128
*    top   2.9 failure during reset

On the 6.0 branch the regression appeared in ca76ef57 instead.

Side note

	#define CLOSE_FD_UP_TO	mgt_max_fd

exposes that we are currently missing to track some fds.

The name CLOSE_FD_UP_TO implies that the value is included.

Also this is the semantics of MCH_TrackHighFd() and relevant for
 #define CLOSE_FD_UP_TO mgt_max_fd

Ref 3c0b8768

still have been happening on the workspace (See: VRG)

from the top down.

Conflicts:
	bin/varnishd/cache/cache_req_fsm.c

The conflict was just the result of cherry-picking changes out of order,
nothing to be worried about.

Conflicts:
	bin/varnishd/cache/cache_vcl.c
	bin/varnishd/cache/cache_vcl.h
	bin/varnishd/cache/cache_vrt_filter.c

It was possible to back-port this change without bringing beresp.filters
and changing the VRT interface. So we get the benefits of this change
and more that will follow and leave the possibility to minor-bump VRT to
back-port beresp.filters in the future if that doesn't break.

This clearly breaks $ABI strict VMODs, but that's part of the deal.

Fixes: #2831

Allow calling it for this purpose only (stop asserting if the
temperature has not changed)

The actual benefit of this will be in follow-up commits

Conflicts:
	bin/varnishd/mgt/mgt_vcl.c

Fixes #2835

arguments could leak from one vtc command to the next where NULL
arguments do not necessarily denote the end of arguments, eg. in
varnish_expect