Use LibC.malloc instead of GC.malloc for LibPCRE allocations

[lbguilherme]

Follow-up on #12451.

This makes the memory management os LibPCRE manual for the stdlib. So any internal allocations are made with the system allocator, leaving less memory being managed by the GC.

Public interface is unchanged.

As an adicional benefit: libpcre doesn't need to be linked anymore if the program doesn't create any regex!

[HertzDevil]

pcre_malloc and pcre_free could still be assigned by external programs, even if they default to LibC.malloc and LibC.free, in which case the allocator (pcre_malloc called by pcre_compile) and the deallocator (LibC.free) in Crystal may not match. So the appropriate fix is to expose pcre_free as usual and then call it directly without assigning to it.

[HertzDevil]

It seems the CI failure here is real. There seems to be some kind of infinite recursion during a GC cycle. No idea why.

[asterite]

We should probably undo this and the other one for 1.6

[straight-shoota]

It's only a problem in the interpreter, right? So we could just undo it there.

[asterite]

Aah... maybe interpreting finalize requires allocating memory for some reason and then it crashes.

[asterite]

I think the problematic line is this:

LibPCRE.free.call @re.as(Void*)

It seems that if you print what's LibPCRE.free in interpreted mode it shows up as a closure, which is incorrect.

I'll see if I can fix this.

[asterite]

I don't think I'll be able to fix this for 1.6 so it might be better to either undo this for 1.6, or conditionally do this depending on whether this runs in interpreted mode or not.