Aftermath of making PCRE2 the default

[straight-shoota]

When we merged the change to use PCRE2 by default in (#12978), several things broke.
For some reason, the CI builds on the PR were all green. Only later we started so say failing builds.
Some of that can be attributed to the docker build images, which originally lacked libpcre2, which we have since added. But I have no idea how the tests in environments that don't use the docker build images and clearly need fixes for PCRE2 support could've possibly succeeded.

The failures are cause by a couple of different bugs, either in the infrastructure setup or with portability of the libpcre2 bindings.
Fixes are in these PRs:

• Fix libpcre2 bindings with arch-dependent types (SizeT) #13088
• [CI] Fix add PCRE2 to GHA cache for win job #13089
• Fix libpcre2 bindings function pointers #13090
• Fix PCRE2 do not allocate JIT stack if unavailable #13100
• Pin use_pcre in build environments where PCRE2 is not yet available #13102

Since they fix independent bugs, each of them is only a partial contribution to make CI green again, but every single one still has failing jobs.
I've merged them all together into a CI test branch to make sure we're good when all are merged.
https://github.com/crystal-lang/crystal/tree/ci/test-pcre2-fixes
CI is all green, except for the release workflow (which is expected; I just included this test for informational purposes) and the occasional interpreter test failure (re-running that again, but this doesn't seem to be related to PCRE2).

So all looks good with these PRs and I'm gonna start merging them (as far as they are approved).

[beta-ziliani]

They are all approved, however, I repeat what I said before: I still think they should all go in the same commit. Ideally each commit should take us from green to green, except if there’s really a necessity. These commits all contribute to fixing the same issue, even if from different angles. Imagine doing a bisect on a regression and finding it fails but for a completely different reason, because your problem was in an architecture that happened to be broken in one of these commits. Each PR in the commit can tackle each issue, no need to such atomic PRs.

[beta-ziliani]

(Note: this is not a hill I will die on)

[Sija]

@beta-ziliani I guess this could be achieved by creating a meta-pr into which all of the above would be merged beforehand.

[straight-shoota]

I see your point. Makes sense from that perspective, although I'm not a fan of merging largely unrelated changes in one. And some of the issues appear dependent on the build environment (that's why we didn't see them directly on #12978, only after updating the build docker images).

I guess an alternative could be to revert #12978, then apply the fixes individually and then re-apply #12978 when it's all green. But it's all a bit messy either way.

I'm happy to squash them all together in a meta PR.