Properly support gcc 4.7 in C++11 (no thread_local yet)

Conflicts:
	core/base/src/TRegexp.cxx
	core/base/src/TSystem.cxx
	core/meta/src/TStreamerElement.cxx
	core/unix/src/TUnixSystem.cxx
Use thread safe alternative to thread_local.

This is doable now that all use of thread_local (on objects) is for function static.

Conflicts:
	core/base/src/TRegexp.cxx
	core/base/src/TSystem.cxx
	core/meta/src/TStreamerElement.cxx
	core/unix/src/TUnixSystem.cxx
white space
Fix detection of thread_local availability when using clang.

From David Abdurachmanov:

At 58 line for Linux you already select R__HAS___THREAD.
Now at 70 line you will select again R__HAS___THREAD for Clang.

Clang by default provides last GPLv2 GCC version aka 4.2.1. You have to explicitly check for Clang 3.3 or higher for thread_local support and it's important to have libstdc++-4.8 (run-time is important). I am not sure about libc++ version.

Thus you fail to select R__HAS_THREAD_LOCAL on Clang, as you assume Clang is GCC 4.2.1. #define __VERSION__ "4.2.1 Compatible Clang 3.6.0 " (from Clang)

Once rewritten the code will compile as thread_local will be selected in C++11 mode with Clang. I tested it locally.

In ThreadLocalStorage.h R__HAS_THREAD_LOCAL is checked before R__HAS___THREAD.

Other projects have the same issue, and it's not so trivial (e.g., https://svn.boost.org/trac/boost/ticket/7473)

The patch below worked fine with Clang 3.6 and GCC 4.9. It's not beautiful/fully correct. Currently I don't have idea how to correctly check for libstdc++ (never found a good way). __GLIBCXX__ might be higher in 4.8.4 vs 4.9.1. It's date based. I doubt there is new special include in libstdc++, which can be checked by __has_include(). Probably it's best to rely on __has_feature(cxx_thread_local) on Clang side, but I haven't check when this was added to Clang. Thus probably should be used in combination with version check (like currently in the patch).

It's quite bad that each compiler attempts to pretend to be GCC. I think, there was some discussions in Clang mailing list that it's time to bump GCC version for their macros, but no one should rely on that.

Have not checked what ICC does and when it added thead_local support (again would require checking for correct libstdc++).