Making space for a swankier similar

[mbauman]

A major task I'd love to accomplish in 1.x is a redesign of similar. This has been discussed in oh-so-many issues (primarily #18161, but also #25107), and I don't want to rehash those discussions all that much. The similar function currently has lots of methods on it, with three "chains" of fallbacks:

┌similar(::AbstractArray)
├similar(::AbstractArray, ::Union{Integer,AbstractUnitRange}...)
├similar(::AbstractArray, ::Tuple)
├similar(::AbstractArray, ::Type, ::Union{Integer,AbstractUnitRange}...)
╘similar(::Array, ::Type, ::Tuple) = Array(…)
┌similar(::Type{T}, ::Union{Integer,AbstractUnitRange}...)
╘similar(::Type{T}, ::Tuple) = T(…)
┌similar(f, ::Union{Integer,AbstractUnitRange}...)
╘similar(f, ::Tuple) = f(…)

(Where ::Array is a stand-in for any object that similar supports).

I'd like to bifurcate this into a value-domain and a type-domain, wherein the type-domain methods become the canonical endpoints. In order to make space for that, though, I believe we'll need to deprecate the second two pairs of chains. Those guys are there to support offset arrays. I believe similar(f, …) can be deprecated in favor of just putting methods on f. similar(Type{<:Array}, ...) is messier, though, since it feels wrong to have Array(undef, 2:3, 2:3) return something that's not an Array.

[nalimilan]

Being able to call similar on a type rather than an instance would also be useful to support promotion for array concatenation in 1.x, see #20815.

[JeffBezanson]

I'm not a fan of the methods with function arguments. For example, from the docstring:

    similar(dims->zeros(Int, dims), axes(A))

should just be written as zeros(Int, length.(axes(A))).