Discover test content stored in the test content section of loaded images.

[grynspan]

This PR implements discovery, but not emission, of test content that has been added to a loaded image's test content metadata section at compile time.

Loading this data from a dedicated section 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++.

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 PR does not include the code necessary to emit test content records into images at compile time. That part of the change is covered by #880 and requires a new language feature to control which section data is emitted to. An experimental version of that language feature is currently available under the "SymbolLinkageMarkers" label.

Because there is no test content in the test content section yet, this PR does not remove the "legacy" codepaths that discover tests in the type metadata section.

Note

This change is experimental.

See Also

#880 #735 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.

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test