This PR adds `-enable-experimental-swift-testing` (and `-disable-xctest` and their inverses) to `swift package init`. These options behave, broadly, the same as they do for `swift test`. They determine which testing library a new package will use and adjust the generated template to match.

It is important to note that any combination of the two libraries is supported: a developer may wish to use only one or the other, or both, or may wish to opt out of a test target entirely. All four combinations are supported, however for simplicity's sake if both libraries are enabled, we only generate example code for swift-testing.

Note that right now, correct macro target support is impeded by apple/swift-syntax#2400. I don't think that issue blocks a change here (since it's in an experimental feature anyway!) but it does mean that `swift package init --type macro --enable-experimental-swift-testing` produces some dead tests. Once that issue is resolved, we can revise the template to produce meaningful tests instead.

Resolves rdar://99279056.

This PR adds `-enable-experimental-swift-testing` (and `-disable-xctest`
and their inverses) to `swift package init`. These options behave,
broadly, the same as they do for `swift test`. They determine which
testing library a new package will use and adjust the generated template
to match.

It is important to note that any combination of the two libraries is
supported: a developer may wish to use only one or the other, or both,
or may wish to opt out of a test target entirely. All four combinations
are supported, however for simplicity's sake if both libraries are
enabled, we only generate example code for swift-testing.

Note that right now, correct macro target support is impeded by
apple/swift-syntax#2400. I don't think that
issue blocks a change here (since it's in an experimental feature
anyway!) but it does mean that `swift package init --type macro
--enable-experimental-swift-testing` produces some dead tests. Once that
issue is resolved, we can revise the template to produce meaningful
tests instead.

Resolves rdar://99279056.

…XCTFail()`.

This PR changes the signature of `assertMacroExpansion()` such that an alternative failure handler can be passed for use when e.g. swift-testing is being used.

Right now, the function calls `XCTAssertEqual()`, `XCTFail()`, etc. on the assumption that the caller is using XCTest. This assumption does not always hold and the dependency on XCTest may prevent a developer from writing effective tests leveraging `assertMacroExpansion()` while also using swift-testing or other testing libraries.

It is not possible for swift-syntax to include swift-testing as a dependency at this time, so the function cannot be amended to directly call the equivalent of `XCTFail()` from that library. Nor can the function check if the current process is running an XCTest-based test because XCTest does not expose API to determine if a test is running.

Until such time as swift-syntax can directly call into swift-testing, developers can do so when calling `assertMacroExpansion()` like so:

```swift
assertMacroExpansion(
  "@foo bar",
  "expanded_foo bar",
  macros: ...,
  ...
) { message, fileID, filePath, line, column in
  Issue.record(Comment(rawValue: message), fileID: fileID, filePath: String(describing: filePath), Int(line), Int(column))
}
```

An improved interface is a future direction.

Resolves #2400.