…ty (swiftlang#931)"

This reverts commit 6a49142.

Revert "Introduce a severity level for issues, and a 'warning' severity (#931)"

…evert swiftlang#931)

Revert "Merge pull request swiftlang#950 from stmontgomery/revert-issue-severity" (swiftlang#950)

This reverts commit 9998633, reversing
changes made to 55d0023.

…evert #931) (#952)

This un-reverts #950, effectively reintroducing the changes recently
landed in #931.

The revert was needed because it revealed a latent bug in the Swift
compiler, tracked by swiftlang/swift#79304. I
reproduced that failure and included a workaround in the second commit
on this PR.

### Checklist:

- [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.

…#951)

This modifies `Package.swift` to enable Library Evolution for builds of
the package.

### Motivation:

I recently landed a change (#931) which passed our project-level CI but
later failed in Swift CI. The difference ended up being due to the
latter building with Library Evolution (LE) enabled, whereas our
project-level CI builds via SwiftPM and does not enable LE. The change
was reverted (#950) but this revealed a gap in our testing strategy. We
should always build these targets with LE enabled.

### Checklist:

- [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.

Fixes rdar://144655439

This updates `Event.JUnitXMLRecorder` to ignore `Issue` instances whose
`severity` is less than `.error` (such as `.warning`).

### Motivation:

The concept of issue severity was recently added in #931 (but was
reverted and re-landed in #952), and that did not adjust the JUnit XML
recorder logic. The JUnit XML schema we currently attempt to adhere to
does not appear to have a way to represent non-fatal issues, so I think
it would be best for now to ignore these issues.

### Modifications:

- Implement the fix and a validating unit test.
- (Drive-by) Fix a nearby test I noticed wasn't actually working as
intended and wasn't properly validating the fix it was intended to.

### Checklist:

- [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.

Introduce a severity level when recording issues

### Motivation:

In order to create issues that don't fail a test this introduces a
parameter to specify the severity of the issue. This is in support of
work added here for an issue severity:
#931

This is experimental.

Example usage:
`Issue.record("My comment", severity: .warning)`

### Modifications:

I modified the `Issue.record` method signature to take in a severity
level so that users can create issues that are not failing.

### Checklist:

- [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.
- [x] Add tests