Sponsored by:	The FreeBSD Foundation

(cherry picked from commit 7fde0187cc443468561f0a30d589ff0cfe45eef5)
(cherry picked from commit 560e22c8fe460e00d16e5268fe1fbb316ad81101)
(cherry picked from commit 5b5fa75acff11d871d0c90045f8c1a58fed85365)

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

Similar commit in main:
(cherry picked from commit 1d386b48a555)

libstdc++ before gcc r244057 expected that libc provided
__cxa_thread_atexit_impl, and libstdc++ implemented
__cxa_thread_atexit, by forwarding the calls to _impl.  Mentioned gcc
revision checks for __cxa_thread_atexit in libc and does not provide
the symbol from libstdc++ if found.

This change helps older gcc, in particular, all released versions
which implement thread_local, by consolidating the implementation into
libc.  For that versions, if configured with the current libc, the
__cxa_thread_atexit is exported from libstdc++ as a trivial wrapper
around libc::__cxa_thread_atexit_impl.

The __cxa_thread_atexit implementation is put into separate source
file to allow for static linking with older libstdc++.a.

gcc bugzilla:	https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
Reported by:	Hannes Hauswedell <h2+fbsdports@fsfe.org>
PR:	215709
Sponsored by:	The FreeBSD Foundation
MFC after:	2 weeks

This is the backing feature to implement C++11 thread storage duration
specified by the thread_local keyword.  A destructor for given
thread-local object is registered to be executed at the thread
termination time using __cxa_thread_atexit().  Libc calls the
__cxa_thread_calls_dtors() during exit(3), before finalizers and
atexit functions, and libthr calls the function at the thread
termination time, after the stack unwinding and thread-specific key
destruction.

There are several uncertainties in the API which lacks a formal
specification.  Among them:
- is it allowed to register destructors during destructing;
	we allow, but limiting the nesting level.  If too many iterations
	detected, a diagnostic is issued to stderr and thread forcibly
	terminates for now.
- how to handle destructors which belong to an unloading dso;
	for now, we ignore destructor calls for such entries, and
	issue a diagnostic.  Linux does prevent dso unload until all
	threads with destructors from the dso terminated.
It is supposed that the diagnostics allow to detect real-world
applications relying on the above details and possibly adjust
our implementation.  Right now the choices were to provide the slim
API (but that rarely stands the practice test).

Tests are added to check generic functionality and to specify some of
the above implementation choices.

Submitted by:	Mahdi Mokhtari <mokhi64_gmail.com>
Reviewed by:	theraven
Discussed with:	dim (detection of -std=c++11 supoort for tests)
Sponsored by:	The FreeBSD Foundation (my involvement)
MFC after:	2 weeks
Differential revisions:	https://reviews.freebsd.org/D7224,
    https://reviews.freebsd.org/D7427