Not intrusive. Significantly speeds up tests on MSVC (for about 3 times).
Finally solves exceeding build time limits on CI with MSVC compilers.
Did not set up PCH for X3, it is fast as-is (tooks only about 2 minutes).
Repository tests reuse PCH from Qi/Karma tests.
It will allow to test `extract_int` properly.
Replacing `boost::integer_traits` with `std::numeric_limits` will not hurt
performance because even MSVC 9/GCC 4.1/Clang 3.0 folds `min`/`max` calls
to a constant at compile time and since C++11 they are even constexpr.
Spirit were assuming that wchar_t is 32-bit and the content is UCS-4.
It is wrong, the actual representation is implementation defined [lex.ccon]/6.
However, on most Unix platforms this assumption is valid and gives the
expected outcome, but on Windows wchar_t is 16-bit and the content is UTF-16.
The concept of ForwardIterator is flawed because it mixed 2 sets of concepts (value access and traversal) into 1 package.
http://www.boost.org/doc/libs/1_65_1/libs/iterator/doc/new-iter-concepts.html
It requires value_type (const)& as return type when dereference is applied, which is not mandatory in spirit parsing. A return type which is convertible to value_type is good enough. ReadableIteratorConcept and ForwardTraversalConcept should be what we need for the iterator check.
For example, the iterator of the range returned by boost::adaptors::transform(std::string, func) is normally not a ForwardIterator. But it fulfills ReadableIteratorConcept and ForwardTraversalConcept and should be able to be parsed by spirit.
