clang-5.0 - clang-11: add emulated_tls functionality to compiler_rt

[kencu (Ken)]

To support thread_local_storage in c++ software, I added the required emulated_tls bits directly into libc++abi.dylib. libc++abi.dylib uses these emulated_tls functions, and copying it into libc++abi.dylib and leaving it there worked nicely to fill that need.

That also allowed all c++ software to find the needed emulated_tls symbols, as they all link against libc++abi.dylib automatically.

However, this does not allow "C" software to find the emulated_tls symbols anywhere, as "C" software does not automatically link against libc++abi.dylib.

There have been very rare build failures for this reason, and I have until now worked around them in other ways.

Upstream clang embeds the emulated_tls functions in compiler_rt.a, and they are therefore linked into all builds automatically. The emulated_tls functions are not automatically added to compiler_rt.a on Darwin, because Darwin >= 10.7 uses a different TLS system (tlv_*).

To support "C" software that uses TLS on < 10.7, you can force it to link against libc++abi.dylib (abomination, but works to find the symblols), or I can rewrite the compiler_rt cmake build scripts to add the emulated_tls symbols to compiler_rt.a on < 10.7.

The latter is no doubt the better thing, and it is exactly what upstream does on all the other systems without system TLS functionality, or without emulated_tls functionality in libc.

I'm not (at the moment) certain how that might or might affect what I've already done in libc++abi.dylib. The reason the symbol was added to libc++abi.dylib directly is that the build was not using it when it was added to compiler_rt, but the last time I tried this was about 2016.