[mono][jit] Devirtualize ldarg(s)+callvirt where possible.

[jandupej]

This addresses Mono:devirtualize sealed calls. If ldarg(a) is succeeded by a callvirt, we devirtualize that call if we can resolve to a final method at that time. Additional conditions apply, mainly no AOT and no generics. The method also must have no arguments except this.

The example from the said issue is now devirtualized and inlined. The codegen for Test(B b) is as follows on arm64:

loWorld_Program_Test__HelloWorld_B_:
0000000000000000        stp     x29, x30, [sp, #-0x20]!
0000000000000004        mov     x29, sp
0000000000000008        str     x26, [x29, #0x10]
000000000000000c        mov     x26, x0
0000000000000010        ldrb    w30, [x26]
0000000000000014        mov     x0, #0x2    ; return 2 from B:Foo
0000000000000018        ldr     x26, [x29, #0x10]
000000000000001c        mov     sp, x29
0000000000000020        ldp     x29, x30, [sp], #0x20
0000000000000024        ret

Given:

public class A 
{
    public virtual int Foo() => 1;
}

public sealed class B : A
{
    public sealed override int Foo() => 2;  // sealed!
}

...
static int Test(B b)
{
    return b.Foo(); // Foo should be devirtualized and inlined
}

[jandupej]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jandupej]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jandupej]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[lewing]

the wasm build test failure was #76621

and should be fixed now

[vargaz]

Looks ok.

[vargaz]

Some of these can be relaxed later.

[vargaz]

This can happen if the vtable is not created yet.

[jandupej]

Added a vtable setup, as in the regular mono_class_get_virtual_method.