Support non-finite floats in exit test captures

[Kyle-Ye]

Allow exit test capture lists to round-trip NaN and positive and negative infinity.

Motivation:

Exit-test value capturing became available in Swift 6.3. Captured values are JSON-encoded in the parent process and decoded in the subprocess. The default JSON coding strategies reject non-finite floating-point values even though Float and Double satisfy the Codable and Sendable requirements for captured values.

Fixes #1836.

Modifications:

Configure matching non-conforming floating-point encoding and decoding strategies specifically for the exit-test captured-value transport, using an internal coding user-info key so other JSON call sites retain their default behavior.

Use "NaN", "Infinity", and "-Infinity" as the JSON string representations, following conventions used by other JSON encoders.

Add a parameterized regression test covering positive infinity, negative infinity, and NaN, including validation that their classification and sign survive the round trip.

AI Disclosure:

Codex was used to help investigate the exit-test capture path, research JSON prior art, and draft and refine the implementation, tests, and PR text. I reviewed the resulting changes and verified the regression test locally.

Checklist:

• Code and documentation follow the style of the Style Guide.
• No public symbols are renamed or modified, so no DocC references need updating.

Future discussion

I suggest this should also be cherry-picked into release/6.4 and release/6.3.

[grynspan]

Thanks for the PR! And thank you for not making the change everywhere we encode/decode JSON (as that would be an ABI break for our JSON event stream and would require Swift Evolution approval).

I am hesitant to approve the change without a better understanding of how unreal values are handled in other systems that use JSON. It would help if you could gather some examples of what other languages, libraries, implementations, etc. are currently doing to handle them.

[grynspan]

I suggest this should also be cherry-picked into release/6.4 and release/6.3.

We are unlikely to take further changes to Swift 6.4.0 at this point in the schedule, however once this PR is merged you can open a new PR targetting release/6.4.x and we can see if it meets the criteria for 6.4.1 (or whatever dot release we're on at that point).

I am not aware of any future planned updates to Swift 6.3. The bar for changes there is exceptionally high.

[stmontgomery]

Aside from @grynspan's remaining style comment, this looks good to me now, thank you!

[Kyle-Ye]

@grynspan The style issue is fixed. Any other suggestion?

[grynspan]

Thanks!