Avoid double TestCase construction when filtering during discovery/execution (platform-agnostic refactor follow-up)

[Evangelink]

Context

Follow-up from the platform-agnostic PlatformServices refactor (Phase 2 filtering, PR #9567 / originally #9555). Surfaced in review of Discovery/UnitTestDiscoverer.cs.

Problem

When a test-case filter is active, a matched UnitTestElement currently causes two UnitTestElement.ToTestCase() constructions:

1. ITestElementFilter.Matches(UnitTestElement) builds a TestCase internally to evaluate the filter (TestElementFilter.Matches → element.ToTestCase() → ITestCaseFilterExpression.MatchTestCase(...)), because the VSTest filter API requires a TestCase.
2. The consumer then builds another TestCase to hand to the sink / execution (discoverySink.SendTestCase(testElement.ToTestCase())).

For large filtered test suites this doubles TestCase allocations for every matched test. It is a transitional artifact of routing the neutral filter through VSTest's MatchTestCase, and it persists through Phase 3 (discovery sink) because the second construction just moves to the adapter boundary.

Resolution direction

Eliminate the round-trip by having the filter evaluate UnitTestElement properties directly (or share a single constructed TestCase) so no redundant TestCase is built per matched test. This becomes clean once filter evaluation is decoupled from ToTestCase() in a later phase of the VSTest-object-model removal (see the Phase 7 cleanup in that effort).

Notes

• No behavior/correctness impact — purely redundant allocation.
• Should be picked up as part of, or after, the later filtering-internals decoupling phase rather than perturbing the byte-for-byte Phase 2 change.