Improve array indexing consistency

This is an extension of #5361.

In grel, if I have an array a which is ["x","y"], say, then I can index a with values -2, -1 ,0 , and 1 with no error and the logic, for the negative values, has a well-defined (and documented) meaning in terms of referencing from the end of the array (i.e. a[-1] is "y" in this instance). And if I go out of bounds with a positive index, such as a[2], then this results in an out-of-bounds error. However, if I go out of bounds with a negative index, such as a[-3], then this just returns the first element of a and never gives an error. I suggest it should give an error.

The use of a second indexing argument to describe a range (e.g. a[0,2]) is also inconsistent, as described in #5361. If we call that second argument M, then in general the last element of the range is the (M-1)th, where negative values of M reference the array from the end as per the first argument (e.g. a[-2,-1] would give "x" in the example array above). However M=0 is an exception since it does not result in the last element of the range being the -1th (i.e. the first from the end) - instead you always get an empty array when M=0 (so a[-2,0] gives [] instead of ["x","y"] which I think would be more consistent). Moreover, there is no out-of bounds condition with the second argument. If M > length(a) then it behaves like length(a) (e.g. a[1,5] gives the same result as a[1,2]), and if M is less than -length(a) then it behaves like -length(a) (which always results in an empty range). Would it not be more consistent to produce bounding errors with the second argument as for the first?

The issue names no files or tests. Start by locating the GREL array-indexing implementation and existing tests for negative and range indices, then compare their behavior with the examples given. Done means the agreed indexing rules consistently report out-of-bounds errors and have regression coverage.