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

We cannot access the varnishd params from a $ABI vrt vmod any more
and doing so does not appear a strong enough reason to change the $ABI.

Previously, pcre limits were taken from the varnish parameters
pcre_match_limit and pcre_match_limit_recursion, now they can be
defined on the re object or match level.

Otherwise parallel make distcheck fails