... such that it can optionally be called before match()

This is in preparation for body matching.

This is in preparation for body matching.

See varnish-cache 7f28888779fd14f99eb34e50f6fb07ea6bbff999

The VCL_REGEX type requires that the pattern consist of constant strings only.

In contrast, with a STRING argument and compilation in this vmod, we can support
patterns to be constructed dynamically in vcl_init {}, which is a relevant
advantage.

I did consider to support both a STRING and a VCL_REGEX argument (both being
optional, requiring at least one to be set) but found no compelling reason
for using the VCL_REGEX type, because the pattern is checked anyway and it
does not make a relevant difference if that check happens at the VCC or
the vcl_init stage.

This reverts commit 0ee2f4ae.

Based on the VRE_unpack() PR in
https://github.com/varnishcache/varnish-cache/pull/3657

As discussed with Geoff, we might still switch to VRE_capture()
once it is cooked, see https://github.com/varnishcache/varnish-cache/pull/3659

When we copy onto ovector[MAX_OV_USED] == ovector[MAX_MATCHES * 2], we
want to make sure that we do not exceed the destination, not the source.

It could infer that the result of a non-NULL cast of task->priv can not
be null, but it doesn't. Sigh.

Ref:
https://github.com/varnishcache/varnish-cache/commit/681c11998ec56dc4460a30585210f95a7850ea3b

... and has at least TASK lifetime anyway.

Thank you for catching this @geoff

test is already included in c01.vtc

Ref c09032032700f91fcf06e3018d206cbb730d1772

ref: 0c74d1b99f1f43fc99725fe14322760afa7858ee

The reason is the same as for
https://github.com/varnishcache/varnish-cache/issues/2708 :

VRT_priv_task may now return NULL for out-of-workspace errors, see
https://github.com/varnishcache/varnish-cache/commit/de2b431086a13b243dc8b3e71cd8697db1df2c7f

- We write our own SYNOPSIS.
- Update Varnish version compatibility statement.
- Remove the reference to the pcre_* varnishd params in LIMITATIONS
  (no longer true).
- Spelling fix