[Runtimes][CMake] Add Distributed to Supplemental build

[edymtt]

Also add a couple modules to use Swift calling conventions and set the correct C++ standard.

Do not enable this yet, as this would relies on a few find modules that
are not available at the moment.

Addresses rdar://151389005

[edymtt]

@swift-ci please smoke test

[compnerd]

Why is distributed special and the only one to perform these checks? I think that we should replicate them across all the builds if we want to perform these.

[edymtt]

Of the Supplemental libraries we are converting, only Distributed and Observation use Swift calling conventions -- since in this rewrite we are trying to apply flags/features only to the libraries that only strictly need those, I thought it was sound not require to apply those to Synchronization and Differentiation.

[compnerd]

Core definitely uses the swift calling conventions as does the Concurrency runtime.

[edymtt]

I agree, my analysis was focused on the Supplemental libraries alone -- Core and Concurrency are running these checks already with CompilerSettings.cmake

[compnerd]

This seems sketchy. We shouldn't be re-generating the configuration for the runtime build, but should distribute it or pull it from the build tree.

[edymtt]

Let me see what I can do -- possibly a find module may help here, need to think about the distribution scenario.

[compnerd]

If we install/export this from Core, find_package(SwiftCore) should be able to wire this up.

[etcwilde]

Once the Core and supplemental libraries are built, the CMakeConfig.h file aren't used by anything so it shouldn't be necessary so installing it isn't great.

You're right that it's sketchy if the projects get out of sync. I do think that the SwiftCoreConfig.cmake should export the appropriate settings and that the supplemental libraries should import them to ensure that the values are kept in sync.

[compnerd]

I think that for the time being we can control that from the outside then; I don't think that we should regenerate it (point into the build tree with CMAKE_CXX_FLAGS).

[edymtt]

I adopted this latter approach -- to better highlight this in code, I have introduced a variable named ${PROJECT_NAME}_PATH_TO_SWIFT_RUNTIME_HEADERS to point at the path containing swift/Runtime and use that as part of target_include_directories, let me know if you think that's appropriate

[compnerd]

_Builtin_float is part of the overlays, we should introduce a find_project(SwiftOverlay) for this.

[edymtt]

Thanks for suggesting this should be more generic -- I was thinking of focusing specifically on _Builtin_float, but that may be too granular.

[edymtt]

(This is a rebase to account for merge conflicts and changes in #81558, no review feedback has been incorporated yet)

[edymtt]

@swift-ci please smoke test

[edymtt]

macOS test failure is unrelated to this change

Unresolved Tests (1):
    lldb-api :: lang/swift/array_bridged_enum/TestArrayBridgedEnum.py

[edymtt]

@swift-ci please smoke test

[edymtt]

@swift-ci please smoke test macOS

[edymtt]

@swift-ci please smoke test