Remove old multi-dimensional array code

[BruceForstall]

After #70271, the GT_ARR_ELEM, GT_ARR_OFFSET, and GT_ARR_INDEX nodes, and their respective GenTree structures and all related codegen, are unneeded and are dead code.

Once we are confident in the direction of #70271 (confident that we don't want to revert to the old mechanism), we should remove all this dead code, as well as the JitEarlyExpandMDArrays and JitEarlyExpandMDArraysFilter configuration values.

category:cq
theme:md-arrays
skill-level:beginner
cost:small
impact:small

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

Issue Details

---

After #70271, the GT_ARR_ELEM, GT_ARR_OFFSET, and GT_ARR_INDEX nodes, and their respective GenTree structures and all related codegen, are unneeded and are dead code.

Once we are confident in the direction of #70271 (confident that we don't want to revert to the old mechanism), we should remove all this dead code, as well as the JitEarlyExpandMDArrays and JitEarlyExpandMDArraysFilter configuration values.

Author:	BruceForstall
Assignees:	BruceForstall
Labels:	area-CodeGen-coreclr
Milestone:	8.0.0

[BruceForstall]

Somewhat related:

There is a StyleCop rule recommending avoiding multi-dimensional arrays:

CA1814: Prefer jagged arrays over multidimensional (code analysis) - .NET | Microsoft Docs

Interestingly, the documentation emphasizes that this is for size, not performance, reasons. Seems extremely unlikely the size case is what led to the rule or that size concerns are frequent when making a choice between the two types. Also seems like a post-hoc explanation, given that the documentation text was relatively recently changed to emphasize this: Update CA1814 and jagged arrays by gewarren · Pull Request #22088 · dotnet/docs (github.com)

It’s not wrong, but possibly misleading if someone sees that warning but doesn’t read the explanation.

Consider getting this rule removed.