DML EP EinSum make more generic to avoid EP fallback

[fdwr]

Problem

Newer models using more novel equations (e.g. bhwc,hkc->bhwk in Segment Anything's encoder or bqc,bchw->bqhw) cause fallback from DML to CPU, yielding performance issues. The EP had some pattern matching to map more common equations to existing DML operators, but the number of permutations was prohibitive and could not catch them all.

Solution

So, ditch the static mapping, and instead handle any 1-input or 2-input cases via remapped strides and a mini-graph of elementwise multiplication & sum reduction (as if DML had a DML_OPERATOR_DOT_PRODUCT that took axes). A subset of mappings still exist for performance (GEMM, pure reduction, transpose...), but they are identified generally rather than via a pattern table. Also...

• ✅ Diagonals are supported now (e.g. iji->i).
• ✅ Removes any remaining DML-specific EinSum GTEST_SKIP statements.
• ✅ Handles any cases up to 8 unique labels (DML dimension limit is 8D).
• ⚠️ >= 3 inputs and arbitrary size inputs via ellipsis are not handled, but we have yet to come across a model.

ℹ️ Note that even with this change such that all nodes are assigned to DML (no CPU fallback), we still end up with multiple partitions because the ONNX EinSum shape inference logic by @peishenyan isn't in ORT yet ⏳.

[smk2007]

void TensorDesc::EnsureStridesExist()

nit: noexcept

---

Refers to: onnxruntime/core/providers/dml/DmlExecutionProvider/src/TensorDesc.cpp:367 in 17b9461. [](commit_id = 17b9461, deletion_comment = False)

[fdwr]

/azp run Big Models,orttraining-amd-gpu-ci-pipeline (Linux_Build_manylinux)

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[fdwr]

The Linux errors and orttraining appear unrelated. Merging...