This modification was done in the old (legacy) JupyROOT, but not
in the new one that was separated from the new PyROOT.

This fixes the display of JSROOT graphics in SWAN.

Otherwise, libcppyy_backend is not found on MacOS when SIP is
activated and when using cppyy alone. Since settings on
(DY)LD_LIBRARY_PATH are ignored, libcppyy_backend is not found.

The previous version was wrongly inverted: the deletions and
additions had to be additions and deletions, respectively.

The previous approach, based on comparing a string containing the
argument types to the signature of the constructor, did not work
in presence of default arguments (see 6467). The new approach
reuses the machinery in place to try the constructors of Dispatcher.

On the other hand, a constructor that accepted a PyObject* is no
longer added to the Dispatcher class, since it was triggering
a corruption of the dispatcher pointer when being attempted
in the reproducer in 6467.

These changes synchronize this part of the code with what is
present in upstream cppyy.

The previous way of calculating the offset was causing a
corruption in a multi-inheritance case described in issue #6376.

Adapted from:
https://bitbucket.org/wlav/cpycppyy/commits/7d9eb4a170ff9e3da9569232ba76ef59c9ee72fd
since CPPConstructor.cxx has changed since last update.

Right after importing cppyy, set batch mode to false to
neutralize the setting to true made by cppyy (in case ROOTSYS
is not defined).

Disabling the batch mode at this point is ok, since the user
settings done via command line (-b) or programmatically are
processed later. This means the setting we do here does not
overwrite a possible user setting.

explanation:
The bug was detected in LCG98 python2,
the try code is importing 'builtins' in python2 and the second import __builtin__ as builtins is never called.
then builtins in python2 is a module
<module 'builtins' from '/cvmfs/sft.cern.ch/lcg/views/LCG_97/x86_64-centos7-gcc8-opt/lib/python2.7/site-packages/builtins/__init__.pyc'>

for that reason _is_ipython = hasattr(builtins, '__IPYTHON__') is false.

I am importing the right one according to the python major version.

If the method __str__ is already defined on the C++ side, don't inject
the cling based pretty printing.

Related to ROOT-10967

Also, add a check when inspecting constructors, to make sure a
copy constructor from a base class is only used if it is public
or protected.

Follow the same strategy adopted for libROOTPythonizations and
libcppyy already.

...since it not used anywhere in Cppyy's code. It used to be used
in TPyClassGenerator.cxx, but the code in that file was completely
commented out.

This will prevent a conflict with a class of the same name that
exists in TPython, as reported by the address sanitizer.

If possible, this should be replaced by the automatic wrapping
of Python callables provided by new cppyy.

This is a workaround for https://bugs.python.org/issue21591 which
affect Python 2 versions before 2.7.9. This includes Python 2.7.5
which is the Python 2 version on RHEL/CentOS 7.

(cherry picked from commit ad2206344917d3e8badde4159049f8432444f5f3)

To prevent deprecation warning.

[CMake][Exp PyROOT] Use ROOT_LIBRARY_PROPERTIES to set suffix to .so and prefix to lib for libcppyy and libcppyy_backend

As a general rule, libraries containing C/C++ extensions that are meant
to be loaded from Python, should not be linked against libPython; the
reason for this is that when these libraries are imported, Python has
already loaded the libPython symbols, and if these are different from
the ones used to link against the extension module a crash can happen.

libcppyy and libROOTPythonizations, being only imported from Python, do
not need to link against libPython.

On the other hand, this is needed for libROOTTPython, which is used only
form C++.

[Exp PyROOT] Raise detailed error when Python version is different from the one used to build libcppyy

Suggested by Chris Burr

MacOS does not allow to run a second thread so fall back to the input
hook because it's the best we can do. This is the same behaviour than in
the old PyROOT.

The PR spawns a separate thread to process ROOT events if we cannot
attach the update mechanism to an exisiting hook such as existing in the
interactive Python mode or for ipython/notebooks.

Also adds backward compatibility for ROOT.PyROOT.StartGUIThread and
shuts down the thread safely at teardown time.

Related to ROOT-10774

It was observed that, when running make package, neither the Python
sources neither their bytecodes were copied in the CPack lib
directory.

The changes in this commit allow both "make install" and
"make package" to work by properly selecting the directory
where the Python sources and bytecodes will be installed.
Moreover, the sources and the bytecodes are installed together.

With the previous install command, the cppyy libraries were
not copied into the CPack lib directory (inside the build dir)
when running make package.

When running "make package", it was observed that copying the
Python source files to runtimedir was incorrect, and the generation
of the bytecodes was failing later too as a consequence.

This change ensures that the Python sources are installed
correctly.

PyROOT/PyMVA related

These changes address the case in which Python 3 has only Interpreter
while Python 2 has both Interpreter and Development. In this case, the
Python used to build ROOT (which requires only Interpreter) will be 3,
but PyROOT (which requires also Development) will be built only for 2.
To achieve this, ROOT and PyROOT/PyMVA use now two different sets of
variables.

Documentation for the whole machinery is also added.

It is also worth pointing out that the entire machinery could be much
simplified by just requiring the following as a prerequisite for ROOT:
        - CMake >= 3.12.4
        - Python-Development package