Int64 bounds-check on array write paths and array methods

[Vizit0r]

1dbf8a9 widened the element read paths. The write paths and the array methods still truncate the Int64 index into a 32-bit local before the bounds check, so an out-of-range index silently hits the wrong element:

var d : array of Integer;
d.SetLength(5);
var i : Integer := 4294967296;
d[i] := 999;     // no error, writes d[0]
d.Delete(i);     // no error, deletes element 0

Changes in dwsArrayExprs / dwsExprs:

(1) Index locals widened to Int64 in TDynamicArraySetExpr, TDynamicArraySetVarExpr, TDynamicArraySetDataExpr, TOpenArrayExpr.GetDataPtr and TArray{Swap,Delete,Copy,Insert,Move}Expr.

(2) TBoundsHelper.BoundsCheck: parameters widened, Cardinal changed to UInt64 in the comparison.

(3) TDynamicArraySetExpr and TDynamicArraySetVarExpr check the bounds themselves before calling SetFromExpr, whose index parameter is NativeInt and therefore truncates on 32-bit targets.

(4) TStaticArrayExpr.GetIndex: NativeUInt changed to UInt64. With NativeUInt the comparison is still 32-bit on a 32-bit target, so Test/ArrayPass/array_bounds_int64.pas fails when the test project is built for Win32.

(5) Raise{Upper,Lower}Exceeded and BoundsCheckFailed take an Int64 index, so the message reports the real index instead of its low 32 bits.

Test/ArrayPass/array_bounds_int64 is extended with the dynamic-array write case and with Delete/Insert/Swap/Move/Copy.

Verified by running the script corpus (SimpleScripts, ArrayPass and the other Pass categories, about 1500 compile+execute runs) on both Win32 and Win64: the extended test is red on current master and green with this change, and no other script changes behaviour.