Debian is apparently offended that pcre2-posix implements POSIX API,
thus it renames all posix-compatible symbols in libpcre2-posix to have the
PCRE2 prefix. But Debian doesn't do anything to pcre2posix.h header,
so any unaware application will get POSIX compatible type names
and function prototypes from pcre2, but actual symbols will come
from libc.
To remedy this enormous incongruity we have to redefine POSIX-compatible
function names in pcre2posix to match Debian's hack.
Caused by 2fcd8c1252. It used the documented pcre API
-pcre_exec(NULL, NULL, NULL, -999, -999, 0, NULL, 0)
to calculate the pcre stack frame size. Unfortunately, modern compilers
broke it by cloning and inlining pcre match() function. 2fcd8c1252
tried to workaround it by setting the stack frame size to at least 500.
It didn't work, 500 is not a universal constant.
Now we fix our copy of pcre to not inline or clone match() - so that
stack frame detection would work again - and detect at cmake time
whether system pcre is broken or usable.
Also use stack, not (much slower) malloc in bundled pcre, unless on Windows
