[CoreML EP] Support Gather with scalar 'indices'

[maxwbuckley]

Description

The CoreML `GatherOpBuilder` rejected rank-0 (scalar) `indices` because CoreML's `gather` requires rank-1+ indices and the obvious workaround would change the output rank — see the `// Don't allow scalar 'indices' input.` comment at `gather_op_builder.cc:90`. This PR performs the workaround internally:

```
reshape(indices, shape=[1]) -> indices_1d
gather(data, indices_1d, axis) -> data_shape with the gather axis = 1
squeeze(., axes=[axis]) -> ONNX gather output shape
```

…in both the MLProgram and NeuralNetwork emitters. The squeeze restores the original ONNX output rank, so caller-visible Gather semantics are unchanged. `reshape` is used rather than `expand_dims` because CoreML internally pads scalars and `expand_dims` on the padded tensor can push the apparent rank past the rank-5 limit on high-rank `data`.

Restrictions:

• `data` must have a fully static shape — we claim a static intermediate shape between gather and squeeze.
• `data` rank capped at 4. The rank-5 case still trips CoreML's compiler with `Invalid rank: 6`, so we keep the conservative bound.

Dynamic-shape and rank-5+ scalar Gather still falls back to CPU (preserves the existing `GatherWithScalarIndices` test, whose data is dynamic-shape).

Fixes #28180.

Motivation

StyleGAN-family generators (StyleGAN, StyleGAN2, GFPGAN, …) select per-layer style codes with a scalar-index Gather. The resulting graph alternates between Gather and the rest of the generator, splitting the CoreML subgraph repeatedly.

On GFPGAN-1024 ([1, 3, 512, 512]), this PR moves all 16 scalar Gathers off CPU and the model lands on a single CoreML partition.

M3 Max, MLProgram, batch 1, 3 × 100-iter steady-state runs (n=300):

	Partitions	Mean	StdDev	P50	P95	P99	Max
origin/main	2	89.68 ms	3.67	87.82	96.71	105.00	108.01
this PR	1	81.77 ms	1.85	80.97	85.98	87.24	88.03

Mean −8.8%, stddev −50%, P99 −17%, max −18.5% — eliminating the CPU↔CoreML round-trip on every scalar Gather both speeds up the steady state and tightens the tail.

Striking secondary effect: the worst-case run with the fix (88.03 ms) is faster than the mean run without it (89.68 ms). Every single fixed inference over n=300 lands below the unfixed average.

Tests

Six new tests in `onnxruntime/test/providers/coreml/coreml_basic_test.cc` covering distinct code paths, exercised on both NeuralNetwork and MLProgram emitters where the dtype is supported:

• `GatherScalarIndicesAxis1` — axis=1, mid-rank squeeze.
• `GatherScalarIndicesAxis0` — axis=0, leading-axis squeeze.
• `GatherScalarIndicesNegativeAxis` — axis=-1, exercises `HandleNegativeAxis`.
• `GatherScalarIndicesFloat16` — fp16 data (MLProgram only, as per `HasSupportedInputsImpl`).
• `GatherScalarIndicesInt64Data` — int64 data, both formats.
• `GatherScalarIndicesRank4Data` — rank-4 data, exercises the supported maximum.

Each verifies CoreML output against the CPU EP reference and asserts `ExpectedEPNodeAssignment::All`. The existing `GatherWithScalarIndices` test (dynamic-shape data) is updated only in its comment to reflect the new precise condition; it still exercises the CPU fall-back as before.

All pass locally on macOS 26.3 / M3 Max.

[maxwbuckley]

@yuslepukhin thank you again for all your support here 👍

[yuslepukhin]

Prefer TensorShapeVector for inline storage.

[yuslepukhin]

Minor gap — rank-1 data with scalar indices: No test for e.g. data shape {6} with scalar index (output is scalar/rank-0). If CoreML's squeeze produces a scalar, this should work, but it's untested. The output-rank check data_shape.size() + indices_shape.size() - 1 > 5 evaluates to 1 + 0 - 1 = 0, which passes, and the rank-4 cap also passes (1 <= 4), so the code would attempt it. Whether CoreML handles a rank-0 squeeze output correctly is the question.

[yuslepukhin]

Potential underflow in output-rank check (line ~225 in the original): data_shape.size() + indices_shape.size() - 1 — when indices is scalar (indices_shape.size() == 0) and data rank is 1, this is 1 + 0 - 1 = 0, which is fine. But for size_t arithmetic, if somehow both were 0 (can't happen since data rank >= 1 is checked), this would underflow. Not a real bug since data rank >= 1 is enforced by ONNX schema and GetShape succeeds, but worth noting the unsigned arithmetic.
This, however, depends on ONNX enforcement code.