JIT: Fix operand evaluation order for GT_INDEX_ADDR (port of #20047)

[AndyAyersMS]

We need to evaluate the array operand first, and it's op1. So evaluate
in that order, and don't allow reversal.

Closes #20040.

[AndyAyersMS]

Description

In "minopts" mode the jit could generate silent bad code for certain sequences where a local was passed by-reference to a call and then used to index an array.

Customer Impact

Impacts simple examples built from Orleans when tiering is enabled. They found and reported the bug.

Codegen bug leasds to wrong behavior or unexpected exceptions. Type and memory safety are not compromised.

If the customer encounters this bug only with tiering enabled they can work around it by disabling tiering.

Tiering is not enabled by default in 2.1 but minopts mode is reachable by other means (eg very large method bodies) and is intended as the high-reliability jit mode. So recommending a fix here even though the likelihood of this surfacing in 2.1 without enabling tiering is small.

Tiering is enabled by default in 2.2 currently.

Regression?

This change in minopts behavior was introduced by #13245 in 2.1, so it is a regression vs 2.0 behavior.

Risk

Fairly low. The jit change prevents an invalid reordering of expressions. A run through ~190K methods jitted with minopts showed about 1K methods with code diffs.

cc @RussKeldorph

[AndyAyersMS]

We are going to fix this in 2.2.