[PyROOT] Disable memory regulator

This feature arguably causes more harm than good.

The idea of the memory regulator was to fix user errors like this:

```
ROOT.gInterpreter.Declare("""
void consume(TTree & t) { delete &t; }
""")

t = ROOT.TTree("tree", "tree")
ROOT.consume(t)
print(t)
```
Instead of a segfault because `t` was deleted, currently ROOT will
print:
```
None
```

Basically, it detected if any object registered in `gROOT` was deleted
somewhere on the C++ side to notify CPyCppyy, which reacts by swapping
a cppyy-specific "None" type into the Python proxy. However, such
proxies are in a state that causes the garbage collector to segfault in
specific environments, and this is not the only problem the memory
regulator has. It was also the source of many poorly understood crashes
in the past.

One other problem is that it only works for types that are registered in
`gROOT`, like TTree, TFile, TH1, etc. If a user tries to access any
other C++ class via Python after it was deleted, it will still segfault.
So the memory regulator only sporadically solves the problem and results
in an inconsistent user experience: the "ROOT-tracked" classes behave
even more different than they already do.

Therefore, this commit suggests to disable the PyROOT memory regulator.

(cherry picked from commit 880d681)

Author: guitargeek

bindings/pyroot/pythonizations/CMakeLists.txt

@@ -121,7 +121,6 @@ set(cpp_sources
     src/RPyROOTApplication.cxx
     src/GenericPyz.cxx
     src/TClassPyz.cxx
-    src/TMemoryRegulator.cxx
     src/TObjectPyz.cxx
     src/TTreePyz.cxx
     src/CPPInstancePyz.cxx

bindings/pyroot/pythonizations/src/PyROOTModule.cxx

@@ -12,7 +12,6 @@
 // Bindings
 #include "PyROOTPythonize.h"
 #include "RPyROOTApplication.h"
-#include "TMemoryRegulator.h"
 
 // Cppyy
 #include "CPyCppyy/API.h"
@@ -63,20 +62,6 @@ PyObject *RegisterExecutorAlias(PyObject * /*self*/, PyObject *args)
 
 } // namespace PyROOT
 
-namespace {
-
-PyROOT::RegulatorCleanup &GetRegulatorCleanup()
-{
-   // The object is thread-local because it can happen that we call into
-   // C++ code (from the PyROOT CPython extension, from CPyCppyy or from cling)
-   // from different Python threads. A notable example is within a distributed
-   // RDataFrame application running on Dask.
-   thread_local PyROOT::RegulatorCleanup m;
-   return m;
-}
-
-} // namespace
-
 // Methods offered by the interface
 static PyMethodDef gPyROOTMethods[] = {
    {(char *)"AddCPPInstancePickling", (PyCFunction)PyROOT::AddCPPInstancePickling, METH_VARARGS,
@@ -164,9 +149,6 @@ extern "C" PyObject *PyInit_libROOTPythonizations()
    PyEval_InitThreads();
 #endif
 
-   // Memory management
-   gROOT->GetListOfCleanups()->Add(&GetRegulatorCleanup());
-
    // Make sure the interpreter is initialized once gROOT has been initialized
    TInterpreter::Instance();