Fixes #42801

Description

ClassLayout::AreCompatible compared the GC slots of the two layouts one by one on every call, i.e. O(slot count) per call. With many distinct but layout-compatible struct types and many copies between them, JIT compilation time was quadratic in (slots × copies).

This change groups class-based layouts with GC pointers into equivalence classes of compatible layouts using a disjoint-set-union structure:

• ClassLayout gets a m_dsuParent pointer: null for layouts that do not participate in the DSU (custom, block and non-GC layouts), a self-pointer for class representatives, or a pointer to the representative of the class the layout belongs to.
• When ClassLayoutTable::AddObjLayout adds a class-based layout with GC pointers, it is compared with the class representatives of the same size and type using the previous slot-by-slot algorithm (kept as ClassLayout::AreCompatibleSlow) and joined with the first compatible one. Since compatibility is equality of the GC slot pattern, a new layout can match at most one class, so the DSU trees stay one level deep and AreCompatible becomes a representative comparison (O(1)).
• In DEBUG builds AreCompatible verifies its result against AreCompatibleSlow.

Custom and block layouts keep the existing pointer-equality path, and non-GC layouts keep the existing early-out path.

Note on the approach vs the issue: the issue proposed building the DSU lazily on the first AreCompatible call (InitDSU + a static initialized flag). This implementation instead maintains the structure incrementally at layout creation time, which keeps AreCompatible parameterless and bounds the extra creation-time cost to one slot-by-slot comparison per same-size representative per created layout (zero for custom, block and non-GC layouts).

Customer Impact

None known today — the issue notes there are currently no known scenarios where this affects JitCompilationTime. This removes the quadratic JIT compilation-time behavior for methods with many copies between distinct but layout-compatible structs, in anticipation of more AreCompatible usages.

Regression?

• Yes
• No

Testing

• Added src/tests/JIT/opt/Structs/StructCopyCompatibleLayouts.cs: two structs with 1000 fields each (1 GC reference + 999 longs, identical layout) and 2000 straight-line copies between them via Unsafe.As, asserting value and GC-reference preservation.
• Local A/B on macOS arm64 (Release, DOTNET_TieredCompilation=0, DOTNET_JitTimeLogCsv), with larger generated variants of the same test (GC slots × copies, JIT time of the copy method):
  • 8000 × 20000: Importation 148.5 ms → 19.1 ms (7.8×), total for the method 300.5 ms → 170.6 ms
  • 16000 × 40000: Importation 550.6 ms → 36.2 ms (15.2×), total for the method 964.9 ms → 445.4 ms
  • After the change, Importation scales linearly with IL size (19.1 ms → 36.2 ms when both N and M double), while before it scaled quadratically (148.5 ms → 550.6 ms).
• Both larger variants and the committed test pass under a Checked build, where the new INDEBUG verification compares every AreCompatible result against AreCompatibleSlow.
• Not addressed here (remaining from the issue): SuperPMI/JitCompilationTime measurements on System.Private.CoreLib and other real workloads to decide whether the optimization should be used by default.

Risk

Low: the equivalence classes are validated against the previous algorithm on every AreCompatible call in DEBUG/Checked builds; custom, block and non-GC layouts are unaffected.