Preprocessor gcc performance regressions

Complicated constructs may present stark differences in expansion times between 4.7.x and 4.8.x/4.9.x
C++11 modes in `g++` as well as between `clang++` and `g++ 4.8.x`. In summary:

- Both `clang++` and earlier versions of `g++` prove far more performant to `g++ 4.8.x`, at times by several factors in **really** complex macro expansions.
- From gcc bugzilla entries http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56746 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53525 this is known to be a performance regression of the 4.8.x branch so far.
- Use of `g++ 4.8.x` with such constructs may result in out of memory errors, system lockup, memory fragmentation and other erratic behavior depending which worst - case scenario of said gcc preprocessor performance regression is met.
- The recommended fix for this kind of gcc performance regression is to pass during invocation of g++, the `-ftrack-macro-expansion=0` flag in order to bypass macro tracking which heavily contributes to this behavior.
- `-fno-builtin-memcmp`  [`regression gcc4.8/4.9`](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43052)
- [`-pie -fPIC -Wl,-z,relro,-z,now -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2`] (http://goo.gl/vVS2Gl), RedHat uses them by default, they better protected buffer/stack overflow exploits, factor productivity dropping 1-4% (to include additional flags to consume [grsecurity-kernel](https://grsecurity.net/) and patched [[1]](https://wiki.debian.org/Hardening), but it works without it); about [RELRO](https://isisblogs.poly.edu/2011/06/01/relro-relocation-read-only/)

Therefore, if g++ is detected as the compiler used during configuration with cmake, this flag should be passed **implicitly** in order to deal with such a `g++` performance regression.

As a result, the memory consumption falls from 3x to 1.5x, we can resume the build on 512mb low-end servers.