[Build system] ROOT can wrongly pick up includes from system directories

[hageboeck]

• Checked for duplicates
  Yes, kind of. I thought that there was a ticket about this by @amadio, but I didn't find anything.

Describe the bug

In a setup where ROOT was installed in a system directory, ROOT was picking up headers from that directory instead of its own.

How to reproduce:

1. echo '#error This is the wrong header' > /my/include/directory/RooSpan.h (or a few other headers).
2. Install some builtins into that directory, e.g. VDT
3. cmake -DCMAKE_PREFIX_PATH=/my/include/directory/ <root> to create a dependency to that include directory.
4. Build.

Now ROOT should find VDT, and add a -I/my/include/directory/ to the compile command, which will accidentally include other parts of ROOT.
The problem is that it's difficult to provoke this error using only one header:

• All core includes are prepended to every compile command, so none of the core includes will be picked up wrongly.
• Library A will always find its own includes in the correct location, because it's also prepended.

The problem only becomes visible when A depends on B and C, and B depends on something in /system/include/ (e.g. VDT), and C is also installed in those system includes. This generates a compile command such as:

-I.../core/x -I.../core/y -I.../core/... -I.../A/include -I.../B/include -I/system/include/ -I.../C/include ...

Instead of picking up C from ROOT's build directory, it now comes from /system/include/.

Expected behavior

ROOT picks up all its own includes first, and system includes last. This can be achieved with -isystem ..., so every -I ... is searched before -isystem ....
In CMake, this means:

• Using imported targets when software comes from system directories (these are implicitly system includes)
• Explicitly marking some include directories SYSTEM.

Setup

Centos8
ROOT installed in /data/software/
ROOT configured with
cmake -DCMAKE_PREFIX_PATH=/data/software ... <root>

[hageboeck]

#8709 fixes a part of this.

What remains to be done:

It is likely that more builtins (or rather FindXXX have to be converted to IMPORTED targets, so they don't provoke this error again. A broken configuration can be detected by

1. Having CMake pick up a dependency in some common directory, e.g. install a lot of builtins there.
2. Either

• Place an entire ROOT installation there, where all headers start with #error This is the wrong header. or
• Search compile_commands.json for -I/my/include/directory/

3. Fix the FindXXX for all dependencies that provoke the above error.