per-task PRIVs.

Fixes: #2749

the purpose of VRT_priv_task()

Previously we used various heuristics (test TCP connection) to avoid
the reschedule if the req was abandonned while on the waiting list.

We also subjected the rescheduling to pool-queue limits like any
new request.

This was all safe because we knew we could clean up the request
state cheaply, even if it was somewhat cumbersome.

Now vmods can have per-task PRIV's and we have no idea what it will
cost us (stack, time, etc) to clean them up, so we cannot burden
J.Random Request who happens to rush the waiting list with the burden.

Fix this by always rescheduling, not subject to pool-queue limits,
and eliminate all the special-casing for exceeded limits, including
the debug feature to force a rescheduling failure and two tests
exercising it.

As a side effect of this, requests on the waiting list gets a
"business class upgrade" over newly arriving requests when there
are no worker threads available.  Given that these requests arrived
earlier, and we already performed work on them, this seems only fair.

Forced to pay proper attention by:      slink

works around #2297

Conflicts:
	lib/libvmod_directors/fall_back.c
	lib/libvmod_directors/hash.c
	lib/libvmod_directors/random.c
	lib/libvmod_directors/round_robin.c

Fixes #2746

Submitted by:	Frederic Lecaille <flecaille@haproxy.com>

Conflicts:
	include/vrt.h

This appears to break the VRT interface, but there are symbols we are
willing to break even on a stable branch because they are needed by
VCC-generated code and off limits to inline C and VMODs.

Refs #2800

Ref: c2888919
     72bacde7
     46f1557d

In other news:  VTEST works.

Fixes: 	#2696

* either NULL or properly named
* only named arguments can be possibly be speficied multiple times
* only named arguments can be optional
* positional arguments could be missing

Fixes #2694

Conflicts:
	lib/libvmod_blob/hex.c

Conflicts:
	bin/varnishd/cache/cache_vrt.c

Fixes:	#2745

Conflicts:
	bin/varnishtest/tests/v00020.vtc

... argument to specify a custom location

Fixes #2742

Submitted by:	Frederic Lecaille <flecaille@haproxy.com>