build: add a CMake based build

[compnerd]

This is a first approximation of a CMake based build for this
repository. The intent here is to localize the build rules for the
repository to allow it to be consumed during the build of the toolchain.
This allows the source list to be maintained in the repository as the
source of truth rather than be explicitly listed in the swift
repository.

For general purpose development, the SPM based build is recommended.
Unless there is a specific need for the tests to be included, testing
should be done via the SPM build.

This change is sufficient to build the content though does not perform
the install or export steps which will be required to consume the
results in the Swift build.

Example invocation:

cmake -B S:\b\16 ^
      -D CMAKE_BUILD_TYPE=Release ^
      -D ArgumentParser_DIR=S:\b\10\cmake\modules ^
      -G Ninja ^
      -S S:\SourceCache\swift-experimental-string-processing
cmake --build S:\b\16

[compnerd]

CC: @rxwei

[compnerd]

@swift-ci please test

[milseman]

The intent here is to localize the build rules for the
repository to allow it to be consumed during the build of the toolchain.

There's a lot in this package that should never be present in a build of the toolchain. Should we separate that out in CMake or another step?

The only modules to land in the toolchain, AFAICT, would be _MatchingEngine and _StringProcessing.

[compnerd]

Those would still need to be exposed to allow for other things to link against the targets. The installation into the toolchain distribution would be controlled at the Swift level, this repository only has to worry about is the bits that are vended and serialized into the module (i.e. if anything uses an import rather than @_implementationOnly import, it should be considered vended and public).

I think that leaving in _Unicode, Prototypes, and VariadicGenerator as build-only targets is fine (they cannot be consumed until a subsequent change). Note that these are publicly visible as per Package.swift. Perhaps we should be removing them from the product list?

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test

[compnerd]

@swift-ci please test macOS platform

[milseman]

MacOS testing is still likely busted...

CC @shahmishal

[shahmishal]

@milseman this is something @lorentey was looking into.

[compnerd]

@swift-ci please test macOS platform

[milseman]

Ping, what should we do here?

[rxwei]

I think we should go ahead and merge this, and switch to add_subdirectory in apple/swift.

[milseman]

Does that need to be a coordinated change? If not, feel free to click the big green button :-)

[compnerd]

No, that is independent - this is the first half, once this is merged and available in the checked out repository, we should be able to adjust the Swift build to do the right thing.