LMAD slicing

[athas]

It is time to support LMAD slicing properly. It works fine in the IR, but exposing it in the source language requires solving three problems:

1. How do we bounds check them?
2. How do we avoid doing in-place updates into slices that have strides of length zero (banning these is not an option)?
3. What should the syntax be?

@coancea says that (1) is not difficult. I have an idea how how to do (2) by simply making it impossible to consume the result of an LMAD slice. This can be done using machinery similar to how we track aliases of top level constants (which also may not be consumed).

The syntax is clearly the most difficult part. In the papers, we use the notation A[L] where L is then an LMAD, but since LMAD notation is something like x+(o1,n1)...(o2,n2), that may be ambiguous with ordinary slicing (and it may also not be the syntax we want).

[FluxusMagna]

Maybe something like this could work?
A{L}[]
then composition could work like
A{L1}{L2}[].

I don't think this would overlap with record syntax as the {x+(o1,n1)...(o2,n2)} expression would not be a valid record.

As an alternate representation of LMADs themselves, perhaps using a futhark data type directly could work, like (i64,[q](i64,i64)), but in this case, if the LMADs are treated as variables, there could perhaps be an overlap with record syntax, although I suspect the position after an array should make it unambiguous.

[athas]

Slicing with a tuple of a particular type, which encodes an LMAD, is a very interesting idea.

[FluxusMagna]

Putting it that way, I guess the rest is sort of obvious. iirc
A[i:j,k] is just sugar for A[i:j][k], so it should be possible to just use the same thing but with a tuple instead of range.