Fix NSLock/Thread subclassing issues

[jmschonfeld]

Currently, NSLock/Thread cannot be subclassed due to the following (or related) issues:

error: cannot inherit from class 'NSLock' (compiled with Swift 6.1) because it has overridable members that could not be loaded in Swift 5.10
Could not deserialize type for 'mutex'
Caused by: module 'CoreFoundation' was not loaded

This is because NSLock/Thread have members whose types come from pthread.h. CoreFoundation currently imports pthread.h in its public headers, and this led the compiler to believe that pthread.h came from the CoreFoundation module and not the SwiftGlibc clang module. This results in a failure because due to the @_implementationOnly import, CoreFoundation is not loaded by clients.

To resolve this, we need to ensure the compiler realizes that pthread.h and the types within come from the SwiftGlibc clang module rather than CoreFoundation. To do this, we import the SwiftGlibc.h header file (from the SwiftGlibc clang module) before importing pthread.h. However, SwiftGlibc.h is not in the default header search paths so we need CMake to lookup the path for SwiftGlibc.h (by asking the compiler) and add the search path when building CoreFoundation. We don't need to do this for the SwiftPM build since it seems that the modules are resolved differently and we do not have this issue (which is also why we can't add a unit test for this).

Resolves #5108, rdar://137716518

[jmschonfeld]

@swift-ci test

[jmschonfeld]

Using a toolchain built with this change, it seems that this resolves the issue for NSLock and its subclasses, but it did not resolve the issue for Thread:

error: cannot inherit from class 'Thread' (compiled with Swift 6.1) because it has overridable members that could not be loaded in Swift 5.10

Could not deserialize type for '_attr'
Caused by: module 'CoreFoundation' was not loaded