The main reason is an upcoming improvement which needs workspace.

But also using workspace here probably does not come with too relevant
an advantage, because regular expression matching and copying are
already expensive, and the need to copy should be the exception.

This is in preparation of an upcoming refactor to heap space.

Add filters: regex objects to perform substitutions on bodies

See merge request !3

If the optional ``asfilter`` parameter to ``re.regex()`` is true, the
vmod registers itself as a Varnish Fetch Processor (VFP) for use in
`beresp.filters` and as a Varnish Delivery Processor (VDP) for use in
`resp.filters`. In this setup, the `xregex.substitute_match()` and
`xregex.substitute_all()` methods can be used to define replacements
for matches on the body.

Example:

	    sub vcl_init {
		new reiher = re.regex("r(ei)h(er)", asfilter = true);
	    }
	    sub vcl_deliver {
		unset req.http.Accept-Encoding;
		set resp.filters += " reiher";
		reiher.substitute_match(1, "czapla");
		reiher.substitute_match(2, "\1\2");
		reiher.substitute_match(0, "heron");
	    }

Ref varnish-cache 478e310a7d2c168e1c361d6f34291177cbc2a889

Code taken from varnish-cache

... 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.