Always use the clang builtin headers for the libclang version we use

Summary:
When we try to parse GCC builtin headers, or headers from other clang
versions, we can easily end up with dozens of parse errors that
eventually reach the error limit. In such cases, kdev-clang becomes
completely unusable.

To prevent this from happening, we filter out the compiler include
path for the builtin headers. This is done using a simple heuristic
by looking for the varargs.h header. For my system, this is only
available in these three folders:

/usr/lib/clang/6.0.0/include/varargs.h
/usr/lib/gcc/arm-none-eabi/7.3.0/include/varargs.h
/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include/varargs.h

All of them are folders for the compiler builtin headers. So now
we always exclude these folders, and instead find the include path
for the folder containing the builtin headers matching the libclang
version we link against. This is required, since libclang does not
find any builtin headers on its own, cf. [1].

[1]: https://clang.llvm.org/docs/LibTooling.html#libtooling-builtin-includes

In the end, this gives us a seemingly well working GCC emulation layer
without the previous pitfalls. The macro compatibility header kept
breaking, and we never had any support for different clang versions.

BUG: 387005

Subscribers: kdevelop-devel

Differential Revision: https://phabricator.kde.org/D12331