Release GIL as much as possible in PySeries and PyDataFrame methods

[itamarst]

Description

Motivation:

1. Holding the GIL can cause deadlocks when parallelization happens: the method awaits Rayon, threads in Rayon try to acquire GIL, deadlock. See Regression in 1.10.0 : Selection of rows hangs indefinitely for a frame contaning a pl.Object series #19358 for an example, but I have seen other cases where this happens.
2. Releasing the GIL enables more parallelism with other Python extensions.

[itamarst]

The ideal would be to have the code calling into Rayon for the Polars release the GIL, so that it would only need to happen once in the code.

[itamarst]

This is plausibly doable by having conditional creation of POOL in polars-core to be either rayon::ThreadPool by default, or a wrapper that releases the GIL if the python feature is enabled. So going to try taht.

[ritchie46]

No, we should just release the GIL on the edge, not deep in Polars on every threadpool access. We should just go to the chore on time and then we're done.

[itamarst]

I am happy to do it the manual widespread small tweaks way, it's just that it feels like a systemic invariant, and putting the burden of a systemic invariant on every single caller (and there are many!) is a recipe for mistakes. Like, someone adds 3 methods in 4 months, and now there's a new place with the problem. Whereas doing it in one place where it's always done by default gives you a systemic solution to a systemic invariant.

The performance cost would be a if unsafe { PyGILState_Check() } == 1 on every POOL.install(), or something similar.

But again, will do it manual update-all-the-functions way if you prefer.