Disable new test on clr interpreter

[BrzVlad]

Test added in #130777.

For code like the one below, where the GetResult of the value task source throws, the correct stacktrace should point to the await as the source of the throw. However, on interpreter, it is pointing to the new instruction.

public static async Task ThrowsSoonValueTaskSource()
{
    ValueTask vt = new ValueTask(new ThrowsSoonValueTaskSourceImpl(), 0);
    await vt;
}

The cause of this seems to be that we only report IL->native offsets for locations where the IL stack is empty, therefore we don't have a location at the await. This seems to be easily fixable via BrzVlad@460eae9. The problem with the fix is that it is a partial revert of #127469 so it has a good chance to lead to regressions on other diagnostic tests.

[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: @steveisok, @dotnet/area-system-diagnostics
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

Adjusts System.Diagnostics.StackTrace async stack trace tests to avoid a failing scenario on the CoreCLR interpreter by isolating the problematic case into its own test and marking it with an interpreter-only skip.

Changes:

• Removes ThrowsSoonValueTaskSource from the shared async test data set used by the existing theory.
• Adds a dedicated [ConditionalFact] for ThrowsSoonValueTaskSource, skipped on CoreCLR interpreter via [ActiveIssue].

[BrzVlad]

@tommcdon Could you validate whether it is safe to bring back reporting for offsets without an empty stack, or whether we should do something else here, to model jit behavior.