Delete VersionsWithType check from embedClassHandle

[jkotas]

It should not be needed. Also, embedClassHandle alternative in embedGenericHandle does not have this check.

[Copilot]

Pull Request Overview

This PR removes the unnecessary VersionsWithType check and associated exception from embedClassHandle to align its behavior with embedGenericHandle.

• Deleted the guard that threw RequiresRuntimeJitException when a type wasn’t in VersionsWithType
• Streamlined embedClassHandle to always emit a ready-to-run helper for the type handle

Comments suppressed due to low confidence (1)

src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs:2739

• With the removal of the VersionsWithType guard, add tests covering cases where a type previously would have failed this check to ensure that embedClassHandle still behaves correctly without requiring a runtime JIT.

            TypeDesc type = HandleToObject(handle);

[jkotas]

Context: #116651

[jkotas]

@davidwrighton This was introduced in https://github.com/dotnet/runtime/pull/51284/files#diff-01e22eff46505ee20d75dd64c72a9eb57d67f28f22a76258300bbe44dca59a14R2168-R2169 . Is there a reason why this check is needed for PGO?

[jkotas]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[davidwrighton]

@jkotas, yes this is needed for PGO scenarios. Notably, there is a problem where we can identify via PGO that a particular path is most desireable, and devirtualize, but if the devirtualization target isn't within the current version bubble, we cannot safely do a devirtualize. If we make this change(which I think makes sense, we need to adjust the devirtualization logic to explicitly check that it is only devirtualizing types which are safe to do so.

We don't have good coverage for this sort of scenario in any of our test suites, so actually writing the test case would be a good to have although decidedly tricky to do.