Use only safe axis types for Broadcast.combine_axes

[timholy]

#30074 used the wrong notion of consistency since OneTo(1) is consistent (wrt broadcasting) with any range, but OneTo cannot handle Slice(-1:1).

I also changed the name to something a bit more "override-worthy." I don't think anyone should ever need to do so (the BroadcastStyle is in charge of output container type), but given that we allow axes to determine output from similar it seemed safer to set this up in a way that isn't inconsistent with potential extensions.

[vtjnash]

Is this really just promote?

[timholy]

Is this really just promote?

It's effectively

promote_rule(::Type{T1}, ::Type{T2}) where {T1<:AbstractUnitRange,T2<:AbstractUnitRange} = UnitRange{Int}

but limited to broadcasting (without the consequent fallout elsewhere). Since BroadcastStyle should resolve the container type, we can aggressively coerce the axes to a common type.

Of course one might wonder whether we want that rule anyway. This is being conservative and limiting the domain of applicability.

[timholy]

To explain the complexities a bit more, consider the following:

Object	Values	axes(_, 1)
-1:1	-1:1	1:3
OneTo(3)	1:3	1:3
Slice(-1:1)	-1:1	-1:1

The Values column is what the object would compare to using for (a, b) in zip(A, B) @test a == b end (i.e., disregarding the axes). None of these should compare as == to one another, since that should require that the values and the axes both match (but see "bugs" below).

These objects raise interesting questions with regards to how construction and convert should behave: one nice "definition" of convert was given by @dlfivefifty here, and by that logic convert should fail for most of the object/type pairs here (specifically for -1:1 to Slice or OneTo, and Slice(-1:1) to UnitRange or OneTo). Since promote gets resolved to a call to convert, these aren't covered by promotion rules.

Bugs noticed while writing this post

Current behavior:

julia> -1:1 == Base.Slice(-1:1)
true

but

julia> using OffsetArrays

julia> collect(-1:1) == OffsetArray(collect(-1:1), (-2,))
false

This, I think, has to be fixed.

More questionable is whether convert(Base.Slice, -1:1) should fail. By the logic above it should. ; if so, I took one line of this PR on the wrong direction, and should have stayed with the constructor syntax. I can fix that before this merges.

[StefanKarpinski]

cc @mbauman

[KristofferC]

Breaks a package on 1.0 so removing from backport.