[wasi] Un-gate Roslyn workspace tests that only need an uncontended wait

[lewing]

Depends on #135335 — do not merge before it. This PR by itself will fail WASI CI; the tests it un-gates need #135335's fix to stop hitting PlatformNotSupportedException.

Background

#134972 made SemaphoreSlim.Wait throw PlatformNotSupportedException on single-threaded runtimes even when the semaphore is available and the call would return immediately without blocking. We worked around it in cdc8d452ae8 ("Gate Roslyn workspace tests on IsMultithreadingSupported") by adding IsMultithreadingSupported to the ConditionalClass on 5 Roslyn-workspace-using test classes, since Roslyn's internal workspace locking uses SemaphoreSlim.

PlatformDetection.IsMultithreadingSupported maps to RuntimeFeature.IsMultithreadingSupported, a real capability flag — WASI stays single-threaded, so it's still false after #135335. That PR only changes whether an uncontended synchronous wait throws, not whether real threading exists. So simply merging #135335 doesn't re-enable these tests; the gate itself still statically skips them.

What this does

Validated on a local build of #135335 applied on top of upstream main, on the CoreCLR WASI interpreter lane, with the IsMultithreadingSupported condition temporarily dropped from each class:

Class	Result with #135335 + gate dropped
ConfigurationBindingGeneratorTests (Microsoft.Extensions.Configuration.Binder)	116 passed, 1 skipped, 0 failed
IncrementalTests (same project)	9 passed, 0 failed
EmitterTests (Microsoft.Extensions.Options, SourceGeneration.Unit.Tests)	75 passed, 3 skipped, 0 failed
EmitterTests (Microsoft.Extensions.Options, SourceGenerationTests)	1 passed, 0 failed
UpgradeToGeneratedRegexAnalyzerTests (System.Text.RegularExpressions)	132/132 failed — unrelated to the semaphore bug

The first four classes' Roslyn workspace usage in these scenarios never actually contends, so they pass once the uncontended-wait fix is in place. This PR drops IsMultithreadingSupported from their ConditionalClass (keeping HasAssemblyFiles where present), relying on #135335 for correctness.

UpgradeToGeneratedRegexAnalyzerTests fails for an unrelated reason: it needs outbound network access to resolve reference assemblies from api.nuget.org via Roslyn's ReferenceAssemblies.ResolveAsync, which the WASI test sandbox doesn't provide (FatalProtocolException wrapping a sockets PlatformNotSupportedException, plus a missing-HOME NuGet failure). It keeps HasAssemblyFiles and gets its own SkipOnPlatform(TestPlatforms.Wasi, ...) with an accurate reason instead of the misleading semaphore comment.

Validation

Build: ./build.sh -s clr+libs+host+packs -os wasi -arch wasm -rf CoreCLR -c Release, clean, 0 warnings/errors.

Test command pattern: ./dotnet.sh build <project.csproj> /t:Test /p:TargetOS=wasi /p:TargetArchitecture=wasm /p:RuntimeFlavor=CoreCLR /p:Configuration=Release.

This was run in a separate validation session, not in this PR's own checkout; the diff here was not itself built/tested against #135335 (doing so would require #135335 applied locally, which isn't appropriate for this branch). Re-validate once #135335 merges and this is rebased.

Note

This PR description was generated with GitHub Copilot.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.