Ensure the order of search paths for C++

[Hexcles]

Prelude: header files are a total mess with so much history burden.

Thanks to the ingenious #include_next hack widely used inside STL (c.f. wrapper headers), the order of search paths does matter, unfortunately. The most important rule for C++ projects is: always include C++ STL headers before system/C headers, as C++ STL will often #include_next the underlying C APIs, wrap them, undefine the names from the C headers, and finally redefine the names to the wrappers, in order to achieve things like precise overloads.

If we switch around the order, things will break miserably, which could easily happen right now if anyone (or some tool) puts -isystem /usr/include in .color_coded. Here's a simple test case:

In an empty folder, test.cpp:

#include <iostream>
#include <cmath>

int main() {
	std::cout << log2f(0.0) << std::endl;
	return 0;
}

.color_coded:

-isystem
/usr/include

(C++ headers will be appended to the search path by defautlts.hpp.)

And then you will see errors similar to those in #139 and #130 . In fact, I speculate this is the root cause of those two issues. Yet I don't have a Mac to be sure.

[jeaye]

Another brilliant change; you're killing it. Thanks again.