Fixes builds with command line tools and macos 10.14.

With 16 threads, the cache is simply too small.
These are thread specific values anyway.

We only use 32-bit builds on Windows, so this warning is just an
annoyance since it cannot be turned OFF.

Visual Studio 2017 doesn't use the registry anymore, so no need to try to find keys. This prevent picking wrong directories in the case there is another version installed on the computer, and prevent also the following errors when starting ROOT:
  RegQueryValueEx: returned 2: The system cannot find the file specified.
  RegOpenKeyEx: returned 2: The system cannot find the file specified.

This reverts commit 316f5535.

the tag called "E" was looked for but its name tested against the
string "N"

efficiently and not variables.

 Fix in LLVM trunk: https://reviews.llvm.org/rL317091

This reverts commit 5993be60, reversing
changes made to f6b75592.

* Revert "[cmake] Narrow the list of included directories."

This reverts commit 88c16588.

* Revert "[cxxmodules] Build cling runtime into module."

This reverts commit 76a9ce75.

This patch splits the headers required at both compile time and runtime.
The Cling_Runtime_Extra module does not require __CLING__ to be defined.
It allows the headers from it to be included at compile time as well
where we do not have __CLING__ defined.

The improvement is by 20% from (260MB to 210MB) and within the reach of the PCH.

The operations done by the LookupHelper are costly in both memory and
performance. Almost every operation requires memory allocation and parsing
of often non-trivial C++ code.

Unfortunately, the LookupHelper is used very intensively by rootcling and
ROOT. The callers usually do not use any caching mechanisms and redo the
expensive operations over and over even though the answer is known to be
the same as before. For instance, building the dictionary of shows:

```
MathCore:
  Cached entries: 217
  Total parse requests: 54051
  Cache hits: 53834
TreePlayer:
  Cached entries: 183
  Total parse requests: 57697
  Cache hits: 57514
```

This patch introduces the first set of caching functionality. In
particular, each LookupHelper::find* function allocates a memory buffer
which is then stored in the clang::SourceManager. We hash the buffer
content and keep a mapping between a hash and FileID and next time we
encounter the same content we do not allocate a new FileID but reuse the
old one. We see decrease in memory footprint by 7% for non-cxxmodules ROOT.

For cxxmodules we see significant reduction of the pcm sizes (by half)
which translates into rss improvements:

```
  master before:
    cpu  time = 0.291462 seconds
    sys  time = 0.064409 seconds
    res  memory = 345.816 Mbytes
    vir  memory = 573.508 Mbytes
  master after:
   cpu  time = 0.235828 seconds
   sys  time = 0.098327 seconds
   res  memory = 260.012 Mbytes
   vir  memory = 377.945 Mbytes
```

Patch by Yuka Takahashi and me.

This is to avoid CMake to fallback to old behavior of
ignoring the value of CMAKE_REQUIRED_LIBRARIES.

In cases where we build ROOT with -Dbuiltin_llvm=Off -Dbuiltin_clang=On
and we have installed both llvm and clang in /usr/ clad will pick up
the clang headers from there too.

This patch gives higher priority to the header files which ROOT is
supposed to use. It fixes a very obscure initialization issue due to
different versions of the ASTContext.h installed and used by ROOT.

Original commit message:
"[modules] Print input files when -module-file-info file switch is passed.

This patch improves traceability of duplicated header files which end up in multiple pcms.
"

This patch already landed in llvm.

Clang emits error when implicit modules was relocated from the
first build directory. However this was biting our usecase where we copy
the contents of build directory to another directory in order to
distribute.

The relevant highlights are:

* Support better Windows (thanks to Bertrand Bellenot!);

* Disabled automatic discovery of system LLVM -- clad should only
  search for LLVM at DCLAD_PATH_TO_LLVM_BUILD. On some platforms
  (discovered by Oksana Shadura via rootbench) clad discovers the
  system LLVM which is compatible in principle but this is not what
  we want for ROOT.

* Implemented -CLAD_BUILD_STATIC_ONLY -- this covers the ROOT usecase
  where we do not need shared objects but link the libraries against
  another shared object (libCling.so). This allows platforms which have
  disabled LLVM_ENABLE_PLUGINS to still build clad and use it. Such
  example is CYGWIN and Windows.

See more at: https://github.com/vgvassilev/clad/releases/tag/v0.2

clad is a C++ plugin for clang and cling that implements automatic
differentiation of user-defined functions by employing the chain rule in
forward and reverse mode, coupled with source code transformation and AST
constant fold.

In mathematics and computer algebra, automatic differentiation (AD) is a
set of techniques to numerically evaluate the derivative of a function
specified by a computer program. AD exploits the fact that every computer
program, no matter how complicated, executes a sequence of elementary
arithmetic operations (addition, subtraction, multiplication, division, etc.)
and elementary functions (exp, log, sin, cos, etc.). By applying the chain
rule repeatedly to these operations, derivatives of arbitrary order can
be computed automatically, accurately to working precision, and using at
most a small constant factor more arithmetic operations than the original
program.

AD is an alternative technique to symbolic and numerical differentiation.
These classical methods run into problems: symbolic differentiation leads
to inefficient code (unless done carefully) and faces the difficulty of
converting a computer program into a single expression, while numerical
differentiation can introduce round-off errors in the discretization
process and cancellation. Both classical methods have problems with
calculating higher derivatives, where the complexity and errors increase.
Finally, both classical methods are slow at computing the partial
derivatives of a function with respect to many inputs, as is needed for
gradient-based optimization algorithms. Automatic differentiation solves
all of these problems, at the expense of introducing more software
dependencies.

This patch allows ROOT to interoperate with clad. Namely, users can ask
the interpreter to produce a derivative or a gradient to a known function.

An illustrative example code for first order derivative:

root [0] #include "Math/CladDerivator.h"
root [1] double my_pow2(double x) { return x*x; }
root [2] auto meta_obj = clad::differentiate(my_pow2, /*wrt 1-st argument*/0);
root [3] meta_obj.dump();
The code is: double my_pow2_darg0(double x) {
    return (1. * x + x * 1.);
}
root [5] meta_obj.execute(1) // no iterations, at the cost of function call.
(double) 2.0000000

Learn more about clad at https://github.com/vgvassilev/clad

Patch by Aleksandr Efremov and me!

Clang allows third party shared libraries to provide user-defined
extensions. For example, a custom libTemplateInstantiation.so can
visualize all template instantiation chains in clang. To enable it
one needs to pass a set of options such as -fplugin.

Cling should be able to inherently work with clang plugins. However,
cling still does not make full use of the clang driver where the plugin
setup is handled.

This patch enables plugins in cling and extends them in some aspects.
In particular, cling allows loading of plugins from shared libraries
but also if they are linked to the same library where cling is. This is
very useful in cases where cling runs itself in a shared library (eg
libCling). Users of libCling (such as ROOT) prefer to keep all llvm and
clang related symbols local to avoid symbol clashes if there is another
version of clang and llvm linked against a package. This can be done by
dlopen-ing libCling with RTLD_LOCAL visibility mode. Then the only way
for clang plugins to work in this scenario is to be linked to libCling.

Patch by Aleksandr Efremov and me.

This patch already landed in https://reviews.llvm.org/rL336660 in Clang.

This was biting us to enable runtime modules in CMSSW.

Detailed desciption:
https://bugs.llvm.org/show_bug.cgi?id=37878

lookupModule was falling back to loadSubdirectoryModuleMaps when it couldn't
find ModuleName in (proper) search paths. This was causing iteration over all
files in the search path subdirectories for example "/usr/include/foobar" in
bugzilla case.

Users don't expect Clang to load modulemaps in subdirectories implicitly, and
also the disk access is not cheap.

if (AllowExtraModuleMapSearch) true with ObjC with @import ModuleName.

We need to move LLVM in ROOT to use the new behavior of policy CMP0051
as it will be removed soon and the warning below will become an error:

CMake Deprecation Warning at interpreter/llvm/src/CMakeLists.txt:15 (cmake_policy):
  The OLD behavior for policy CMP0051 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.