NativeAOT: GVM analysis only runs on canonical form for shared instantiations

The whole program analysis of GVMs currently assumes the call will be lazy and will go through the type loader. If we enable devirtualization for shared generic virtual methods, the following test will fail:

```csharp
class TestGvmDependencies
{
class Atom { }

class Foo
{
public virtual object Frob()
{
return new T[0, 0];
}
}

class Bar : Foo
{
public override object Frob()
{
return new T[0, 0, 0];
}
}

public static void Run()
{
{
Foo x = new Foo();
x.Frob();
}

{
Foo x = new Bar();
x.Frob();
}
}
}
```

We don't expect `Atom[,]` to exist during scanning because GVM analysis only ever sees `Frob<__Canon>` (we deliberately ignore the `Frob` call and consider it just `Frob<__Canon>`). We do this for two reasons - compile speed, and size. GVMs expand very aggressively and not precomputing all the types that we could build lazily saves us both.

We could in theory have a mode that does the full analysis and analyzes `Frob` that then forces both `Atom[,]` and `Atom[,,]` to exists, but we don't have it yet.

The GVM devirt under NativeAOT has been limited to struct instantiations only for now. We could allow reference types if the other analysis mode is added.

This is one of the things where RyuJIT-as-IL-scanner would help because then we would do this devirt during scanning already and GVM analysis never gets in the picture (it's not considered a GVM call in the first place).

_Originally posted by @MichalStrehovsky in https://github.com/dotnet/runtime/pull/130202#issuecomment-4889098083._

Start with the NativeAOT GVM analysis and devirtualization paths described in the issue, using the TestGvmDependencies scenario as the regression case. Determine how shared reference-type instantiations such as Frob should be analyzed; done means the scenario can devirtualize without missing Atom[,] or Atom[,,] dependencies.

Written by the indexing model from the issue text.