[RDF,PyROOT] Rename TTreeAsFlatMatrix header to PyROOTHelpers and change namespace from Detail to Internal

Needed for MSVC, since it does not understand -fvisibility=hidden.

Clang defines __GNUC__ then complains it doesn't know the
warning options from GCC since it doesn't know -Wpragmas
either:

core/clingutils/res/TClingUtils.h:28:32: warning:
 unknown warning group '-Wclass-memaccess', ignored [-Wunknown-warning-option]
 #pragma GCC diagnostic ignored "-Wclass-memaccess"

Also avoid warnings about deprecated register due to Qt4

If libPyROOT is loaded with gSystem->Load, the static
initialization block in TMemoryRegulator.cxx is executed and
ends up invoking PyCFunction_New, which causes a crash from
Python 3.7. The crash is due to Python not being initialized.
This also happens when using TPython from C++, since Python
has not	been initialized when TPython is used.

Note that when loading libPyROOT from ROOT.py, which is what
happens when someone uses PyROOT, the Python interpreter already
exists and is initialized, so invoking PyCFunction_New does not
crash.

This fix moves the creation of gObjectEraseCallback away from
the static block in TMemoryRegulator in order to prevent the
issue described above.

in order to verify that the same objects read from two different
TFiles pointing to the same physical file have different pointers.

This reverts commit 22c5dd19.
root.exe and hsimple do not need GeomPainter.

Now calling

  auto f1 = TFile::Open("hsimple.root");
  auto f2 = TFile::Open("hsimple.root");
  auto d = f2->GetDirectory("hsimple.root://);
  assert(d == f2);

return f2 rather than f1 (because it is first in the list of files)

Deprecate afdsmgrd bonjour castor geocad globus gviz hdfs krb5 ldap memstat odbc qt qtgsi rfio table:

This emits a warning when the module is enabled.
We have no tests for these modules, we expect no actual usage of them, and there are better alternatives.

The warning:

core/base/src/TSystem.cxx:1149:14: warning: ‘char* strncat(char*, const char*, size_t)’ accessing 1 byte at offsets 0 and [-2147483647, 2147483648] may overlap 1 byte at offset [0, 2147483649] [-Wrestrict]
       strncat(buff, c+1, n);
       ~~~~~~~^~~~~~~~~~~~~~

is wrong because gcc8 does not (can not) detect that the input is already trimmed to kBufSize [strlcat(inp, c, kBufSize);]
and that the buffer is also used in a segmented way (4 portion of kBufSize each).

Switch from strncat to strlcat to suppress the warning.
Add an assert expressing the known precondition.

This reverts commit 912ee789.

The apparent overlap mentioned in:

  Before reaching the changed line, c is set to be an index into buff,
  so the strings can overlap if no copy is performed, and that leads
  to unpredictable behaviour.

can not happen by construction as the buffer is 'segmented' in 4
independent parts.

The original warning is inaccurate as by construction lentit+ktitle is less than the size of the buffer (1024)
because of the line:

      if (lentit > 250-ktitle) lentit = 250-ktitle;

However, the warning detections implementation (as of gcc 8.2) can not detect this (even if the actual length
is use in any away, for example:

      strncpy(&line[ktitle],memberTitle,std::min(sizeof line - ktitle, lentit));

still produce the warning.

So we switch from strncpy to strlcpy for which gcc 8.2 does not (yet?) warn.

/local2/pcanal/cint_working/rootcling/root/core/meta/src/TClass.cxx: In member function ‘virtual void TDumpMembers::Inspect(TClass*, const char*, const char*, const void*, Bool_t)’:
/local2/pcanal/cint_working/rootcling/root/core/meta/src/TClass.cxx:686:14: warning: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
       strncpy(&line[ktitle],memberTitle,lentit);
       ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/local2/pcanal/cint_working/rootcling/root/core/meta/src/TClass.cxx:684:28: note: length computed here
       Int_t lentit = strlen(memberTitle);
                      ~~~~~~^~~~~~~~~~~~~

Both pt and ru are 5 characters long, so this is safe.

Others need it, e.g. cpack and distsrc in the next commit.

Adding RPATH entries manually and via CMAKE_*RPATH* facilities may lead
to conflict of authorities. This instance in particular tries to add the
same RPATH entry twice (fails on MacOS).

GCC 7 and below don't know -Wclass-memaccess and emit
a warning about the unknown warning we are trying to
shut up. This suppresses that warning too.

GCC 7 complains that it doesn't know the warnings we are trying
to disable, so we just exchanged one kind of warning for another
before. This way is more convincing to GCC that we know what we
are doing.

Before reaching the changed line, c is set to be an index into buff,
so the strings can overlap if no copy is performed, and that leads
to unpredictable behaviour.

Fixes: ROOT-9601