Check for ComInterop case for async variants in crossgen2

[jakobbotsch]

This check was added in the VM, but a similar check must be added in crossgen2 to avoid generating calls to async variants of ComImport methods in crossgen2.

Fix #129739

[Copilot]

Pull request overview

Updates crossgen2’s JIT interface token/method handling to avoid resolving async variants in cases where no callable runtime async entrypoint will be generated (notably for COM-imported methods), addressing an async-variant resolution crash/assert scenario.

Changes:

• Introduces a shared eligibility check (HasCallableAsyncVariant) for deciding whether an async variant can be used.
• Uses the shared check when selecting the “other variant” in getAsyncOtherVariant.
• Uses the shared check when resolving CORINFO_TOKENKIND_Await tokens to an async-variant method (or returning null to force fallback resolution).

[jakobbotsch]

I suppose it means that adding ComInterop to an existing interface that already was compiled against with crossgen2 can also cause this issue. I am not sure what the best way to solve the problem would be.

1. Accept it
2. Add some form of versioning to throw away the compilation
3. Bring back async thunks for this case
4. Try to compile the async version from the COM interop stub's IL stub
5. Move the COM interop stub to transient IL and get an async version that way

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.

[jakobbotsch]

PTAL @AaronRobinsonMSFT

I'll open a follow up issue about handling the potential versioning problem highlighted above. This fix should at least get outerloop clean.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.