after using pcre2_match_data_create_from_pattern() to create match_data.

This requires a test in configure.ac for whether UTF8 is enabled in
the PCRE2 lib against which the VMOD is built.

and recursion_limit, and test compile option use_offset_limit

note that I don't know at the moment how to test never_backslash_c

(and some notes about what will be needed to test options that are
not yet supported)

now with tests for allow_empty_class, anchored and bsr=unicode

For compatibility with native VCL regexen.

(could probably get rid of more)

required by recent changes in Varnish trunk

UTF-16 and -32 would require strings to include null bytes; this is
the case for all code points that correspond to ASCII. But a VCL
literal STRING by definition may not have a null byte (see vcl(3)).
So we couldn't have a pattern in a literal STRING, and that's the
show stopper. We also could not match regexen against literal strings;
that might not happen much in production, but it could in principle,
and the VMOD would have match against literal strings in the vtc tests.
So, maybe some day when we support matching against BLOBs (although
for that, we'd have to declare the pattern in a BLOB, which might
be just too odd).