Abstract VSTest execution input in PlatformServices (Phase 4 of platform-agnostic effort)

[Evangelink]

Why

Part of the multi-PR effort to make src/Adapter/MSTestAdapter.PlatformServices platform-agnostic by removing its dependency on the VSTest object model (Microsoft.TestPlatform.ObjectModel). VSTest coupling moves up into the adapter layer (src/Adapter/MSTest.TestAdapter); the platform-services engine stops reading VSTest-specific data off the test.

This is Phase 4 (execution input): it makes the execution engine (TestExecutionManager + partials) operate on the neutral UnitTestElement model for everything that reads test metadata.

What

• Boundary conversion. TestCase → UnitTestElement now happens at the adapter boundary (MSTestExecutor, and the unit/integration test harnesses). Each element carries:
  • a neutral, string-keyed ExecutionContextProperties bag holding the host execution-context (a.k.a. TCM) properties. TcmTestPropertiesProvider.GetTcmProperties now returns IReadOnlyDictionary<string, object?> keyed by property id — lossless because GetTestContextProperties only ever consumed TestProperty.Id.
  • an opaque, [NonSerialized] HostRecordingHandle holding the originating VSTest TestCase.
• Neutral reads. RunTestsAsync (tests overload), ExecuteTestsAsync, ExecuteTestsInSourceAsync, ExecuteTestsWithTestRunnerAsync, and MatchTestFilter no longer read VSTest test-case properties. Filtering, parallelization grouping (element.DoNotParallelize / element.TestMethod.FullClassName), ordering (managed type/method gated by HasManagedMethodAndTypeProperties, matching the old GetManagedType()/GetManagedMethod() semantics), source resolution (UnitTestElement.WithUpdatedSource), and TCM→TestContext (the neutral bag) all run off the neutral model.
• Internal discovery. TestCaseDiscoverySink now collects UnitTestElement directly (no TestCase round-trip).

VSTest TestCase remaining — as an opaque handle only

The engine still hands the test's TestCase to two boundary services — the result recorder (ITestResultRecorder, unchanged from Phase 5) and the deployment service (ITestDeployment, TestCase-based) — but treats it as an opaque handle: it obtains it via UnitTestElement.GetOrCreateHostTestCase() (the host's original test case when present, else a single cached materialized one) and reads nothing VSTest-specific off it. This deliberately keeps recorded results byte-for-byte identical to baseline: the unchanged recorder receives the exact same TestCase the engine passed before this change, so TRX/TCM association and any host/data-collector-injected properties are preserved. This is not "100% TestCase-free" — see remaining work.

No behavior change

Pure refactor: the executed test set, order, parallelization grouping, TCM/TRX properties, and recorded results (fields, Id, outcome, messages, attachments, timings) are preserved for both the RunTestsAsync(tests) and RunTestsAsync(sources) paths. The filter Id is filename-based (source-path-independent), so source resolution does not affect the filtered set.

Source resolution and a tracked latent bug

Correct element-based source resolution is required for the deployment path (issue #6713 — the executed assembly must load from the deployment directory). TestMethod.CloneWithUpdatedSource has a latent bug: it assigns AssemblyName/MethodInfo on this instead of the returned clone, tolerated only by the current call order. Rather than change that shared primitive here, this PR leaves the buggy method untouched for the existing ToTestCase/test-case-filter bridge callers and adds a new, correct CloneWithSource that the neutral engine uses via WithUpdatedSource. The bug is tracked by #9573 and referenced in comments next to both coexisting clone methods. Correct deployment-directory loading is verified by RunTestsForTestShouldLoadSourceFromDeploymentDirectoryIfDeployed.

Remaining work (later phases)

Neutralizing the two boundary services — so the engine no longer holds a TestCase handle at all — is deferred and is the prerequisite for Phase 7 (cutting the Microsoft.TestPlatform.ObjectModel dependency from PlatformServices):

• The result recorder neutralization (moving the element → TestCase reconstruction, incl. the host-handle / TCM / data-collector fidelity, out of the engine) — a dedicated recorder piece.
• Deployment (ITestDeployment.Deploy, which also flows IFrameworkHandle) — folds into the deployment/contexts phase (Phase 6).
• The single VSTest bridges that stay in PlatformServices for now: TestResultRecorderExtensions, UnitTestElementSinkExtensions, TcmTestPropertiesProvider, TestCaseExtensions/UnitTestElement.ToTestCase.
• Unifying the two clone methods once CloneWithUpdatedSource mutates this instead of the returned clone #9573 is addressed.

Verification

• build.cmd -c Debug green across all TFMs (net462, net8.0, net9.0, UWP, WinUI).
• MSTestAdapter.PlatformServices.UnitTests (897) and MSTestAdapter.UnitTests (21) green; the deployment-directory test passes explicitly. Recorded-result fidelity is covered by MSTestExecutorTests (asserts RecordStart against the original host TestCase) and the integration harness's recorded-result assertions — the recorder is unchanged and receives the same TestCase as baseline.
• MSTest.IntegrationTests (discover→run harness) green — the only failing test seen was OutputIsNotMixedWhenTestsRunInParallel, a known [CICondition(ConditionMode.Exclude)] timing-flaky parallelism assertion unrelated to this change.

Stacked PR

Base = dev/amauryleve/vstest-decoupling-base (the accumulation base that already contains Phase 2 #9555 and Phase 3 #9566). Phase 1 + Phase 5 are already on main. This should be reviewed/merged after the earlier phases reach main.