This PR uses the experimental symbol linkage margers feature in the Swift compiler to emit metadata about tests (and exit tests) into a dedicated section of the test executable being built. At runtime, we discover that section and read out the tests from it.

This has several benefits over our current model, which involves walking Swift's type metadata table looking for types that conform to a protocol:

1. We don't need to define that protocol as public API in Swift Testing,
2. We don't need to emit type metadata (much larger than what we really need) for every test function,
3. We don't need to duplicate a large chunk of the Swift ABI sources in order to walk the type metadata table correctly, and
4. Almost all the new code is written in Swift, whereas the code it is intended to replace could not be fully represented in Swift and needed to be written in C++.

This change will be necessary to support Embedded Swift because there is no type metadata section emitted for embedded targets.

The change also opens up the possibility of supporting generic types in the future because we can emit metadata without needing to emit a nested type (which is not always valid in a generic context.) That's a "future direction" and not covered by this PR specifically.

I've defined a layout for entries in the new swift5_tests section that should be flexible enough for us in the short-to-medium term and which lets us define additional arbitrary test content record types. The layout of this section is covered in depth in the new TestContent.md article.

This functionality is only available if a test target enables the experimental "SymbolLinkageMarkers" feature and only if Swift Testing is used as a package (not as a toolchain component.) We continue to emit protocol-conforming types for now—that code will be removed if and when the experimental feature is properly supported (modulo us adopting relevant changes to the feature's API.)

See Also

#735
#764
swiftlang/swift#76698
swiftlang/swift#78411

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.