fix: bounds-check the field index in construct_with_layout

[0xull]

fixes #23337.

rust-analyzer analysis-stats . panics while const-evaluating a tuple struct constructor called with more arguments than the struct has fields:

index out of bounds: the len is 2 but the index is 2
at ra-ap-rustc_abi-0.166.0/src/lib.rs:1706

Evaluator::construct_with_layout writes each incoming operand into the result buffer at the layout offset for that operand's index. the operands come from the mir call terminator while the layout comes from the adt definition, and nothing checks that the two agree on how many fields there are. so, once the call supplies more operands than the layout has fields, FieldsShape::offset indexes its offsets vector past the end and panics.

but the loop already handles the neighbouring failure, so the shape of the fix was somewhat decided for me. it returns MirEvalError::InternalError when the byte range for an operand falls outside the result buffer, and this adds the matching check one line earlier for the field index itself. i used FieldsShape::count for the correct bound for all four field shapes, so this one comparison covers unions and arrays along with ordinary structs, covering all its six call sites.

after the change the const fails to evaluate rather than taking the process down.

i would want to note one thing about the reproducer in the issue. so far, it contains two syntax errors and neither turns out to be load-bearing (though), because the same panic happens for a fixture that parses cleanly:

struct Color(u8, u8);
const GOAL: Color = Color(0xCF, 0xCE, 0xC1);

here, rustc still rejects that with E0061, so it is ill-typed rather than valid, but no parse recovery is involved. i used the well-formed version as the regression test since it pins down the actual precondition, and also i confirmed separately that the fixture from the issue passes as well.

ai disclosure: i triaged the panic (and its backtrace) with help by claude (web), but final code and commit
message are by me.