JIT: escape analysis for object fields

[AndyAyersMS]

Add connection graph nodes and retyping for object fields. All GC fields of objects are tracked as one virtual field.

Also add support for GT_LCL_FLD and GT_STORE_LCL_FLD for local structs.

Contributes to #104936 and #108913

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[AndyAyersMS]

Formatting errors seem like they may be from #115348 ?

[kendall1997]

Created #115416 to try fix the issue.

[AndyAyersMS]

Looked at one of the arm32 failures. In this case we have code like:

        var fullInput = new[]
        {
            new { utf8Bytes = new byte[] { 0x40 }, output = "@" },
            new { utf8Bytes = new byte[] { 0xC3, 0x85 }, output = "[00C5]" },
        };

and we can prove the arrays and objects don't escape. However we fail to notice the string assignment because we lack the equivalent of GTF_VAR_CONNECTED handling for field stores. That is

STMT00027 ( INL01 @ 0x00D[E-] ... ??? ) <- INLRT @ ???
               [000099] hA-XG------                         *  STOREIND  ref   
               [000098] ---X-------                         +--*  FIELD_ADDR byref  <>f__AnonymousType0`2[System.__Canon,System.__Canon]:<output>i__Field
               [000096] -----------                         |  \--*  LCL_VAR   ref    V07 tmp3         
               [000097] -----------                         \--*  CNS_STR   ref   <string constant>

does not create a connection graph edge V07.f <- unknown. So we retype the objects too aggressively.

Also I think we're being too pessimistic handling the Vxx <- Vyy.f case; currently we model this as

   Vxx <- Vyy.f
   Vxx.f <-> unknown (escapes)

this second rule since there is no immediate way to evaluate Vyy.f.f.

But it seems like we should defer the second rule here, and after building the connection graph we should connect Vxx.f to the things Vyy.f can refer to.

For example

   X a = new X();
   a.f = new Y();
   a.f.f = new Z();
   Y y = a.f;
   ...

Here we know what y.f points to. But I also think it's ok to be conservative here for now, so will leave this as a future enhancement.

[AndyAyersMS]

Going to defer this until after .NET 10.