Support strides option for slice operator

[huningxin]

This is a separate issue of previous discussion #369 (comment) focusing on steps/strides support (proposed by @fdwr, thanks!).

A stride of slice operator indicates how many elements to advance when copying within the input tensor along a dimension. It is widely supported. However, today's WebNN slice operator only support stride 1. We observed there are real models using slice with stride > 1. When targeting those model to WebNN, the slice op has fallback to other execution provider and causes performance drop.

Frameworks' support

• TensorFlow's strided_slice supports optional strides.
• ONNX's Slice support optional steps.
• NumPy's ndarray slicing and striding supports start:stop:step notion.

Native ML API's support

• DML DML_SLICE1_OPERATOR_DESC supports optional InputWindowStrides.
• CoreML slice_by_index supports optional stride.
• TFLite strided_slice optional strides.

Proposal

dictionary MLSliceOptions : MLOperatorOptions {
  sequence<[EnforceRange] unsigned long> strides;
};

MLOperand slice(MLOperand input,
                sequence<[EnforceRange] unsigned long> starts,
                sequence<[EnforceRange] unsigned long> sizes,
                optional MLSliceOptions options = {});

Revision History:
10/29/2004: only support positive strides.

[a-sully]

Seems reasonable to me 👍

[huningxin]

Discussed with @fdwr offline, the negative strides may have ambiguities due to starting index. A separate reverse operator is proposed in #773. I'd update the proposal to support the positive strides as the starter.

[fdwr]

I'd update the proposal to support the positive strides as the starter.

Alrighty. Yeah, I can draw a diagram later illustrating the ambiguities related to negative strides, but positive strides are very clear.