Use CoreFoundation from Swift

[eleanxr]

Addresses #82 .

This PR replaces the contents of Frameworks/CoreFoundation with the contents of the CoreFoundation subdirectory for the Swift 5.7.1 release (https://github.com/apple/swift-corelibs-foundation/tree/swift-5.7.1-RELEASE/CoreFoundation).

In my fork, I tagged the version corresponding to the unmodified import to serve as a branch point for future updates (https://github.com/deleanor/ravynos/tree/import-swift-cf-swift-5.7-RELEASE).

To see the specific changes to the Swift CF implementation that were required to work with the current RavynOS frameworks, it's probably easiest to view the diff in the CoreFoundation directory against the import tag: https://github.com/deleanor/ravynos/compare/import-swift-cf-swift-5.7-RELEASE...deleanor:ravynos:swift-cf-RunLoopWithKevent

Considerations:

• As noted in the issue, I applied the upstream patch to use Kevent within CFRunLoop mentioned in #209 (https://github.com/apple/swift-corelibs-foundation/pull/3004).
• I attempted to make the minimal set of changes to the CF implementation to aid in future updates.
• There are many preprocessor guards of the form #if TARGET_OS_MAC && !__RAVYNOS__. This is because ravynos/include/TargetConditionals.h ends up defining TARGET_OS_MAC. It may be beneficial to either augment that header to have a TARGET_OS_RAVYNOS or in the longer term make RavynOS fully compatible with TARGET_OS_MAC. For now, we defer to the alternative TARGET_OS_BSD branches where necessary by adding a || __RAVYNOS__ where they align.
• As noted in the issue, a small shim was necessary in Foundation to handle cases where Foundation objects were passed into CF and CF is expecting type information via CFRuntimeBase.
• The Swift-provided CoreFoundation.h header includes CFXMLNode.h and CFXMLParser.h when the deployment runtime is not Swift, but those files don't exist in the repository as far as I can tell. I conditionally excluded those for now, and I had to exclude CFXMLInterface for the same reason. There are versions of those files in Apple's open source CF if we want to try and adapt those later.
• I've been able to test very little. I can currently only test the beginning of WindowServer initialization, but it makes it to the same place on my VM that the main branch makes it to. I'm not sure what other executables to test, but I'm open to suggestions. I also wrote a simple test for CFRunLoop that appears to work (https://github.com/deleanor/ravynos-cf-test). I'd love to hear additional suggestions for testing, but short of writing a large test suite to go with this I'm not sure what else I can do in that area at the moment. Future options include using the Foundation test suite that ships with swift-corelibs-foundation, but that would be down the road because it requires Swift language support.

[eleanxr]

I think I was probably overly optimistic opening this PR. I've been reading more documentation/code for toll-free bridging to try and figure out how to implement it correctly in a follow-on issue and I'm pretty sure the other frameworks are going to break if this were to get merged. I've found a few locations where frameworks are assuming that they can cast freely between some of the CF and Foundation types. For example, CGImageSource casts from a CFURL to a NSURL to pass into O2ImageSource. So I think this is not ready yet until I can either get bridging in or find a more complete workaround.

[lin72h]

Good work takes time. Thanks for your persistency