Make fallback similar methods less specific in axes

[jishnub]

The idea of this PR is to make the fallback similar method less specific in the axes, to make it easier for packages to extend similar for custom array types without encountering ambiguities.

The way the fallback similar method is defined currently makes it tricky for custom array types to extend similar without running into ambiguities. For example, an array type defined as:

julia> struct CustomArray{T} <: AbstractVector{T}
                       sz :: Int
                   end

julia> Base.size(C::CustomArray) = (C.sz,)

julia> Base.getindex(C::CustomArray{T}, i::Int) where {T} = T(i)

julia> Base.similar(C::CustomArray, ::Type{T}, ax::Tuple{Vararg{Int}}) where {T} =
                       Array{T}(undef, ax)

julia> function Base.similar(C::CustomArray, ::Type{T}, ax::Tuple{Vararg{Union{Int, SOneTo, Base.OneTo{Int}}}}) where {T}
                       sz = last.(ax)
                       Array{T}(undef, sz)
                   end

julia> c = CustomArray{Int}(4)
4-element CustomArray{Int64}:
 1
 2
 3
 4

faces the error

julia> similar(c, Float64, (SOneTo(2), Base.OneTo(3)))
ERROR: MethodError: similar(::CustomArray{Int64}, ::Type{Float64}, ::Tuple{SOneTo{2}, Base.OneTo{Int64}}) is ambiguous.

Candidates:
  similar(A::AbstractArray, ::Type{T}, shape::Union{Tuple{SOneTo, Vararg{Union{Integer, Base.OneTo, SOneTo}}}, Tuple{Union{Integer, Base.OneTo}, SOneTo, Vararg{Union{Integer, Base.OneTo, SOneTo}}}, Tuple{Union{Integer, Base.OneTo}, Union{Integer, Base.OneTo}, SOneTo, Vararg{Union{Integer, Base.OneTo, SOneTo}}}}) where T
    @ StaticArrays ~/.julia/packages/StaticArrays/80e5O/src/abstractarray.jl:149
  similar(C::CustomArray, ::Type{T}, ax::Tuple{Vararg{Union{Base.OneTo{Int64}, Int64, SOneTo}}}) where T
    @ Main REPL[6]:1

Possible fix, define
  similar(::CustomArray, ::Type{T}, ::Union{Tuple{SOneTo, Vararg{Union{Base.OneTo{Int64}, Int64, SOneTo}}}, Tuple{Union{Base.OneTo{Int64}, Int64}, SOneTo, Vararg{Union{Base.OneTo{Int64}, Int64, SOneTo}}}, Tuple{Union{Base.OneTo{Int64}, Int64}, Union{Base.OneTo{Int64}, Int64}, SOneTo, Vararg{Union{Base.OneTo{Int64}, Int64, SOneTo}}}}) where T

Stacktrace:
 [1] top-level scope
   @ REPL[8]:1

After this PR,

julia> similar(c, Float64, (SOneTo(2), Base.OneTo(3)))
2×3 Matrix{Float64}:
 0.0          6.9398e-310  6.9398e-310
 6.9398e-310  0.0          6.9398e-310

This definition of similar feels a bit icky, as

julia> Tuple{} <: StaticArrays.HeterogeneousShapeTuple
true

however,

julia> Tuple{} <: Tuple{Vararg{Int}} <: StaticArrays.HeterogeneousShapeTuple
true

and Base defines similar for Tuple{Vararg{Int}}, which is strictly more specific. This makes similar(::AbstractArray, ::Tuple{}) call the Base method.

This PR also makes something like this work:

julia> similar(zeros(), (1,1,1,SOneTo(1)))
1×1×1×1 Array{Float64, 4}:
[:, :, 1, 1] =
 1.0e-323

where the SOneTo isn't present in the first three arguments.

[mateuszbaran]

We had something similar before #823 and it was changed to avoid invalidations. Have you checked if it doesn't re-introduce them?

[jishnub]

The invalidation check passed, so this PR doesn't add to invalidations already present on master, at least on recent versions of Julia

[mateuszbaran]

I see, Julia must've become better at avoiding invalidations.