PERF: Reintroduce a global GEOS context

_Originally reported by @caspervdw in https://github.com/pygeos/pygeos/issues/192_

In https://github.com/pygeos/pygeos/pull/113, the global GEOS context was eliminated in favor of a context that was initialized and destroyed in every function. This was necessary for multithreading.

However, in https://github.com/pygeos/pygeos/pull/182, @jorisvandenbossche encountered a performance hit coming from this intialization/finalization of the context.

I am thinking especially of the deallocation of Geometry objects. It would probably be hard to time this, but I think that destroying a array with lots of geometries has taken a performance hit after #113.

Maybe the functions that need the GIL anyway can benefit from keeping a global GEOS context around. I would like to explore this, and maybe we can also use a global WKB reader / writer and WKT reader / writer for speeding up single-geometry construction, and repr and str functions.

[kylebarron]

In #113, the global GEOS context was eliminated in favor of a context that was initialized and destroyed in every function. This was necessary for multithreading.

Might be helpful to edit the first comment to specifically point to https://github.com/pygeos/pygeos/pull/113. I was wondering how #113 related to multithreading 😄

[jorisvandenbossche]

We would also have to make sure to properly cleanup a theadlocal GEOS context after the thread stops. Not sure if there are hooks for that.

One option might be to define a module clean up for lib that can destroy the context (https://docs.python.org/3/c-api/module.html#c.PyModuleDef.m_free). Another option could be to put the context in a small extension type PyObject as well, and define a dealloc (although that might still require an explicit decref on module clean-up, leading to the same issue, not sure)

But indeed, on the short term only tackling the cases that already have the GIL will give the biggest benefit and is much simpler.