PERF: release the GIL in hotloops

[neutrinoceros]

This allows multi-threading parallelism to beat single-thread walltime performances (on Python 3.12). By my measurements, it's possible to obtain better performances on multiple threads for sorted datasets and up to a couple (2 or 3) fields. I suspect this means cache misses are the main hurdle, which hinders the benefit of doing multi-threaded computations, but it's still the only option for datasets that are too large to be copied accross proceses, so I think it's worth it.

[neutrinoceros]

Turns out this makes perfs drastically worse for a large-ish number of fields (tested with 8). Single thread perf seems unbeatable in this regime but multi-threading still does about 10 times worse with this patch, so I "unmerged" it but suppressing the merge commit from main.

[neutrinoceros]

I restored this merge for two reasons:

• I don't want to pollute changelogs generated with gh changelog new with unmerged-PRs
• I think releasing the GIL is still the right thing to do at the C level; the responsibility of using a lock or not should be left to user code, and it's simple enough to implement on that side that I don't think I should add more complexity within the library.