Serialization traits for data dependencies

[grynspan]

Experimental .serialized(for:) trait. Example use cases:

import Foundation

@Test(.serialized(for: \ProcessInfo.environment))
func `HAS_FREEZER environment variable`() {
  _ = setenv("HAS_FREEZER", "1", 1)
  #expect(FoodTruck.hasFreezer)
  _ = setenv("HAS_FREEZER", "0", 1)
  #expect(!FoodTruck.hasFreezer)
}

@Test(.serialized(for: *))
func `Uses lots of different state, seriously, just scads of it`() { ... }

Resolves rdar://135288463.

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

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[grynspan]

@swift-ci test

[stmontgomery]

While this is an experimental feature, should the env var name include the word "experimental"?

[stmontgomery]

Now that this _postingTestStartedAndEndedEvents function has been extracted, it looks like both of its call sites are now nested within try await Test.withCurrent(step.test) scopes. If that's true, then can you remove this withCurrent(...) call as redundant, now?

[stmontgomery]

Is there a reason to avoid storing this in case type(_:) of the Kind enum above? Is it because you can't use nonisolated(unsafe) on an enum case associated value?

[stmontgomery]

It'll be good to include discussion of this behavior in any documentation article we eventually write, since I imagine folks will wonder what happens if two dependency serialization traits conflict.