[1.0-dev] Store indices in CartesianRange

[timholy]

The main advantage of this change is that you no longer lose type information from CartesianRange(indices(A)). The types of the specific AbstractUnitRanges are important for similar, if you're using non-1 indices. It's also kind of nice to be able to write CartesianRange{3} rather than CartesianRange{CartesianIndex{3}}.

Because this changes the parametrization of an exported type, and also introduces a new depwarn, this is queued for after 0.6.

CC @JKrehl.

[JKrehl]

Not having understood all the ends this change seeps into yet, one question:
Why are the ranges forced to use Int? There are credible use-cases for using other data types for indexing an array (sparse arrays of low occupancy, lots of small arrays).

[timholy]

Because the indices in CartesianIndex are Int. I'd rather get the conversion error in the outer loop than the inner.

[JKrehl]

And also changing CartesianIndex to be based on NTuple{<:Integer} is maybe to much for this PR.

[JKrehl]

@timholy
Looks good to me overall except the little utility/magic function ur_int, wouldn't it be better to use convert(AbstractUnitRange{Int}, ...) for this?

[timholy]

That's not defined currently, but heck yeah, that's a better way to "spell" that conversion. Updated.

[tkelman]

bump, revisit?

[timholy]

Yup, on my agenda. I'm a bit focused on finishing #22210 now, but once the dust settles there I'll rebase this.

[tkelman]

0.7 section, right?