[Concurrency] Split out the default cooperative executor into a separate opt-in library

[kubamracek]

Currently, the Embedded Swift's libswift_Concurrency.a includes an implementation of a default cooperative executor (via CooperativeGlobalExecutor.cpp) inside, and the mechanism to use a user-provided executor instead relies on the linker preferring code from a .o file and/or order of libraries listed on the linker time. This feels unintuitive and possibly error prone, so this PR changes the setup: Instead, libswift_Concurrency.a stops including any global executor, and the user is expected to either explicitly link a new library, libswift_ConcurrencyDefaultExecutor.a, or link in their own executor. If they don't do either, they'll receive a (pretty self-explanatory) linker error about missing symbols like swift_task_enqueueGlobalImpl, etc.

[kubamracek]

@swift-ci Please Build Toolchain macOS Platform

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci Please Build Toolchain macOS Platform

[al45tair]

the mechanism to use a user-provided executor instead relies on the linker preferring code from a .o file and/or order of libraries listed on the linker time. This feels unintuitive and possibly error prone, so this PR changes the setup:

That makes me a bit sad; this was the normal way to do things back before dynamic linking and IDEs became popular and everyone forgot how linkers work :-) I suspect a lot of lower level embedded developers would still recognise this approach as they tend to interact with linkers more directly, but hey, the world appears to have moved on.

I think I agree that splitting it out is probably the right choice :-)

[kubamracek]

@swift-ci please test