Implement Python's slice syntax instead of .slice and .splice

[masak]

This would obviate #238, or at least provide a serious contender/complement.

• Reading slices. From what I can see in the Python REPL, a Python slice is a list when you ask it. I don't think I mind having a separate Slice class for this, but I'm willing to be convinced either way. (Update: I doubt a separate class is needed, at least for this case. We can tell statically whether something is a read or a write. If it's a read, then the slice is just another Array.)
• Writing slices. This whole thing is way preferable to having a .splice method à la #238. The splice method is artificial; the slice syntax is consistent and plays on treating a part of an array as a temporary array on its own. (Cf. Java's .subList method.)
• Deleting slices. That is, we could deliberately interact with #290's prefix:<delete> operator. The semantics'd be the same as assigning the slice to [], removing it. (Just like in Python.) Unlike the train wreck in JavaScript where we leave holes.
• Shallow-cloning arrays. With array[:], you'd get a fresh copy of an array.
• Avoiding new references. By assigning to array[:] on the lhs, you replace the whole array but keep the array reference. (I actually like this, even though on the face of it, it's wildly inconsistent with the last point.) I have no idea what it'd take to "register" array slices as an lvalue; the whole thing sounds like Lisp's setf again.

I thought about being a rebel and making the syntax be array[x..y] instead of Python's array[x:y]. The former seems more sensible to me. (Except, ugh, that it should be array[x..^y] because the slice is half-open.) But... let's not introduce more problems than we need; let's stick with array[x:y] (and array[x:y:z]) for now.

There's the small matter of negative indices, which work in Python and are an integral part of list slices there. I'm willing to have negative indices work in 007 too, I think.

[masak]

Note: tc39 currently has a slice syntax proposal going.

[masak]

Reading the tc39 proposal, I'm struck by a number of things:

• Using Perl 6 .. and ..^ (and ^..) syntax might not be such a bad idea after all. I updated #401 accordingly, with both syntax.array.slice.python and syntax.array.slice.p6.

• Right, ranges! That is, passing a Range value as an index to an array should also work. Strictly speaking that's completely unrelated to introducing slice syntax, though. It's more a matter of being able to overload the array indexing operation enough. I don't have any immediate ideas for how to do this nicely. (Is this an example of double dispatch?)

[masak]

But... let's not introduce more problems than we need; let's stick with array[x:y] (and array[x:y:z]) for now.

I no longer believe that to be the right trade-off. Instead I think we should do everything with the already proposed range syntax, with syntactic infinities (#517), and possibly also with a syntactic Whatever (no issue for that yet), both as range endpoints and stand-alone. Details to follow.

[masak]

Another nice force multiplier would be being able to do array[from..to] .= reverse(); that is, combining array slicing and the .= operator.

As far as I can see, that follows immediately. What would be most impressive, however, would be if the optimizer carried enough information to know not to create any intermediate arrays while reversing in-place.