[Threading][TSan] Fix TSan errors from lazy init on Linux.

[al45tair]

Move the TSan functionality from Concurrency into Threading. Use it in the Linux ulock implementation so that TSan knows about ulock and will tolerate the newer swift_once implementation that uses it.

This should also slightly improve the performance of Concurrency, since the tsan tests will be inlined rather than it always doing a subroutine call.

rdar://110665213

[al45tair]

Explanation: The Linux implementation of swift::once uses a custom lock implementation so that it fits into a swift_once_t (which is necessary because the compiler reserves space for those when generating code). TSan doesn't see the lock in question as it has no interceptor for it, so we need to tell TSan about the lock otherwise it'll generate errors for accesses made during a lazy Swift initializer. The original PR (#66721) added a use of dlsym(), which then broke the freestanding build, necessitating #66883. Since the changes in #66883 require #66721, and since we would never want one without the other, I've put both into this one cherry-pick.
Risk: Low. First part affects TSan on Linux only; second part fixes a resulting issue with freestanding builds.
Original PR: #66721 + #66883
Reviewed by: @yln @weissi (#66721), @mikeash (#66883)
Resolves: rdar://110665213 (#66721), rdar://111214571, rdar://106555012 (#66883)
Tests: This PR adds a new test, test/Sanitizers/tsan/once.swift, that explicitly tests this case. Before the code changes, the test fails. After the code changes, it passes. Without #66721, the freestanding build will fail. With it, that passes too.

[al45tair]

@swift-ci Please test

[al45tair]

@swift-ci Please test

[al45tair]

preset=stdlib_S_standalone_minimal_macho_x86_64,build,test
@swift-ci please test with toolchain and preset