Workaround parse errors due to missing implementation of __has_include

GCC reports the following two defines as built-in:

#define has_include(STR) has_include(STR)
#define has_include_next(STR) has_include_next(STR)

There are no definitions of has_include{,_next} available in clang
though, leading to parse errors like:

2 problems encountered:
"Function-like macro 'has_include' is not defined" "" [ (1, 12) -> (1, 25) ]
"Broken c++11 setup (__has_include)" "" [ (4, 9) -> (4, 14) ]

This then propagates to all kinds of issues, most notably when parsing
Qt headers. There, we suddenly fail to realize that the compiler is
C++11 capable (__has_include(<atomic>) errors out), and more.

Overall, the language parser is suddenly completely broken. We now
catch these two function macros and skip them, to ensure they never
override the builtin functionality of clang. This fixes the new unit
test and also makes KDevelop behave properly again with newer Clang
when parsing Qt 5 code bases.

The question now is: Why do we use GCC by default to find the built-in
defines? I thought we'd default to Clang since a long time by now...