…wiftlang#733)

This includes an API proposal and code changes to introduce new API for
custom traits to customize test execution.

View the [API
proposal](https://github.com/stmontgomery/swift-testing/blob/publicize-CustomExecutionTrait/Documentation/Proposals/NNNN-custom-test-execution-traits.md)
for more details.

One of the primary motivations for the trait system in Swift Testing, as
[described in the vision
document](https://github.com/swiftlang/swift-evolution/blob/main/visions/swift-testing.md#trait-extensibility),
is to provide a way to customize the behavior of tests which have things
in common. If all the tests in a given suite type need the same custom
behavior, `init` and/or `deinit` (if applicable) can be used today. But
if only _some_ of the tests in a suite need custom behavior, or tests
across different levels of the suite hierarchy need it, traits would be
a good place to encapsulate common logic since they can be applied
granularly per-test or per-suite. This aspect of the vision for traits
hasn't been realized yet, though: the `Trait` protocol does not offer a
way for a trait to customize the execution of the tests or suites it's
applied to.

Customizing a test's behavior typically means running code either before
or after it runs, or both. Consolidating common set-up and tear-down
logic allows each test function to be more succinct with less repetitive
boilerplate so it can focus on what makes it unique.

- [x] Code and documentation should follow the style of the [Style
Guide](https://github.com/apple/swift-testing/blob/main/Documentation/StyleGuide.md).
- [x] If public symbols are renamed or modified, DocC references should
be updated.