which is its dautgher, in order to restore the symmetry with the C++ interfaces,
where TDirectory::Get does not exist.

this allows to create files with this factory pattern

myFile = ROOT.TFile.Open("myfile.root")

the pythonizations are three:
1. A C++ pyz to provide attr syntax. For example:

myfile.mydir.mysubdir.myHist.Draw()

2. A C++ pyz to allow users to invoke the templated method TDirectory::WriteObject<T>. For example:

h = ROOT.TH1F("h","",10, 0, 1)
myfile.WriteObject(h)

3. a Python pyz which implements TDirectory::Get in terms of the pythonized attr syntax

these are internal Cppyy utilities. In principle it would be better to
expose them in cppyy and use them in PyROOT and not duplicate the code.
This commit at least avoid to duplicate the code only once.

pythonisations are lazy: upon class usage, the class gets pythonised, not before.
For some core classes though, for example TDirectory, lazy pythonisation is not possible.
This change introduces non-lazy pythonisations to address such cases.
The syntax for lazy pythonisations becomes

@pythonization()
def pythonize_myclass(klass, name):
  ...

to make a pythonisation non-lazy:

@pythonization(lazy=False)
def pythonize_myclass(klass, name):
  ...

TNtuple and TNtupleD will inherit from TTree all the pythonizations
added in the TTree pythonizor. Pythonizations on a superclass are
inherited by a subclass if the superclass adds a new method or
pythonizes an existing method that is not redefined in C++ in
the subclass. If the subclass redefines the method in C++, a
reinjection of the pythonization needs to be done in the subclass.

Pythonizations that are common to TTree and its subclasses were injected
by checking if the given class `InheritsFrom` TTree. This operation is
costly and, since it is executed for every new class that is referenced
from the user application, it triggers the loading of libTree even if
the user Python script does not use any class from it.

The proposed solution uses an explicit list of classes to be pythonized.
While being less flexible (subclasses are not automatically picked and
pythonized) it does not suffer from the aforementioned issues.

Note that, if in the future PyROOT allows users to define their own
pythonizations, user classes that subclass TTree will still be able to
inject any desired behaviour, including the pythonizations of TTree.