First fix for the UnsafeAccessors functionality in the interpreter

[davidwrighton]

• We are generating a non-instantiated target method desc to be returned via the ResolveToken api in the JIT during UnsafeAccessor codegen
• This is apparently sublty different than what the JIT does for other uses of generics

[Copilot]

Pull Request Overview

This PR fixes a subtle issue with UnsafeAccessor functionality in the interpreter by modifying how method instantiation is handled during token resolution. The fix changes the instantiation flag from TRUE to FALSE when creating associated method descriptors for generic UnsafeAccessor methods.

Key Changes

• Modified method instantiation behavior in UnsafeAccessor token generation to align with JIT expectations
• Changed the allowInstParam parameter from TRUE to FALSE in FindOrCreateAssociatedMethodDesc call

[jkotas]

I would expect that this can manifest as a functional bug even outside interpreter. Do we have a sufficient test coverage for these cases?

[davidwrighton]

Probably not. I suppose I should write that test, since this may be a general bug. Sigh. I'll hold off on fixing this for a bit while I see if I can get it to fail.

[davidwrighton]

Ah, actually from what I can see, the problematic paths through the getCallInfo either land in a CORINFO_VIRTUALCALL_LDVIRTFTN which in the JIT doesn't respect a flag around having an extra param arg (and it doesn't matter, since it never should logically be set). OR they resolve around constrained method calls or access checks, none of which are performed by the IL that the UnsafeAccessors generate. So, it looks like we just got lucky here. We DO already have code which exercises the failure path, its just that the JIT happens to ignore the only really unfortunate bits of data which get stuck into the output of the getCallInfo code.