Add MLSS heuristics for gfx1150/gffx1151 archutectures

[urpetkov-amd]

Add graph-based AMDMLSS auto-selection for Strix Halo

Summary

This change adds conservative, model-name-independent AMDMLSS auto-selection to
the MIGraphX execution provider.

The policy inspects the ONNX graph immediately before MIGraphX compilation and
decides whether convolution operations should be forced through AMDMLSS.

The final behavior is:

• gfx1200 and gfx1201: preserve the existing behavior and automatically
  request AMDMLSS for convolution graphs.
• gfx1150 and gfx1151: use graph features to decide whether to request
  AMDMLSS for convolutions.
• Other architectures: do not automatically force AMDMLSS.
• Explicit mlss_use_specific_ops configuration: remains authoritative and
  bypasses the automatic decision.
• Uncertain graphs: remain on normal MIGraphX backend selection.

Motivation

AMDMLSS can improve convolution performance on Strix Halo, but forcing it for
every model also causes significant regressions.

The objective was to enable useful AMDMLSS coverage while ensuring that all
measured red models remain outside the automatic enable region.

Feature extraction

The offline analysis considered graph features that can also be reproduced
from the ModelProto available in the execution provider:

• Convolution count.
• FP16 and FP32 convolution-weight ratios.
• Total, mean, and maximum convolution-weight sizes.
• Input and output channel statistics.
• Maximum channel count.
• Mean kernel area.
• Ratios of 1x1 and 3x3 convolutions.
• Strided and dilated convolution ratios.
• Grouped and depthwise convolution ratios.
• Maximum input element count.
• Maximum input spatial size.
• Maximum input channel count.

Weights represented as graph initializers and weights produced by ONNX
Constant nodes are both recognized.

The analysis also builds a structural group signature from operator counts,
convolution structure, and tensor types. StratifiedGroupKFold keeps
structurally equivalent model variants in the same fold and reduces leakage
between related input-size or precision variants.

Policy derivation

For gfx1150 and gfx1151, convolution is forced through AMDMLSS only when:

1. The graph contains at least one convolution with a known weight tensor.
2. Every recognized convolution weight is FP32.
3. The graph has a known, nontrivial input shape.
4. The number of 1x1 convolutions is at most 19/60 (approximately 31.7%) of
   all recognized convolutions.

Architecture behavior

gfx1200 and gfx1201

The existing automatic behavior is preserved. A graph containing a recognized
convolution receives an effective MLSS operation list of "conv".

gfx1150 and gfx1151

The conservative graph policy described above is applied.

Other architectures

The automatic policy returns false and leaves MIGraphX backend selection
unchanged.

Explicit override

When a user sets:

mlss_use_specific_ops=conv

the explicit value wins on every architecture and for every graph partition.
MIGraphX still retains responsibility for handling unsupported convolution
configurations.

MXR cache correctness

The ONNX graph itself does not change when AMDMLSS is enabled, so graph and
architecture hashes alone cannot distinguish an MXR compiled with "conv"
from one compiled with the default empty operation list.

The MXR prefix now includes a hash of the final per-graph
effective_mlss_use_specific_ops value:

• Automatic match or explicit conv: hash of "conv".
• Automatic non-match or no explicit option: hash of "".

This effective prefix is used consistently for:

• Static-shape MXR loading and saving.
• Dynamic-shape/batch compilation caches.
• EP-context MXR references.

The cache key represents the effective compilation behavior rather than the
source of the decision. An automatic "conv" decision and an explicit
"conv" decision can therefore safely share the same compiled artifact.