Deprecate similar(f, …) in favor of just dispatching directly on f(…)

[mbauman]

Fixes #26433.

Previously, OffsetArrays used similar(dims->zeros(dims), axes) to add offset support for the base functions that created arrays: zeros, ones, trues, falses, and fill. It was a bit of a strange construct — the function specified the "internal" array around which OffsetArrays would wrap. This deprecates that similar method in favor just structuring the method tables of those five functions in a manner that is conducive for overloading with offset axis argument(s). Paired with JuliaArrays/OffsetArrays.jl#43 to match the changes in test/TestHelpers.jl.

[mbauman]

Just a note that I first attempted to coalesce all these functions around an AbstractArray{T}(dims_or_axes…) constructor. I still think that may be a good idea, but it was turning into a rabbit hole and is a new feature so I decided to punt on it until later. I left that first commit here that does so — it can be squashed out on merge but I think it's nice to leave here in the GitHub PR as a starting point if we ever decide to implement that feature.

The biggest reason not to couple it with this change was simply that it became quite disruptive — it meant that fill(true, dims) returned a BitArray. That led me down quite a rabbit hole trying to figure out how we could come up with a consistent rule for returning arrays or bitarrays… and it's not something that I particularly wanted to tackle so close to a release.

[mbauman]

I've added NEWS and deprecations for the newly-tighter ones and zeros methods… but now I'm running into a test failure I don't quite understand:

f5575() = zeros(Type[Float64][1], 1)
@test Base.return_types(f5575, ())[1] == Vector

With these additional deprecations, I'm now getting Any from return_types. I'm not entirely sure what that test is meant to be testing… as it appears we again have "too many methods" (#5575)? It's a little odd, as (::Type, ::Integer) is still only selecting one method:

julia> methods(zeros, Tuple{Type, Int})
# 1 method for generic function "zeros":
[1] zeros(::Type{T}, dims::Union{Integer, AbstractUnitRange}...) where T in Base at array.jl:401

So I'm not sure what to do with that...

[vtjnash]

The zeros function (currently) recurses aggressively. The test is there to make sure the compile stops trying to follow the possible branches in a reasonable time, without losing accuracy.

[mbauman]

Thanks. So the fact that I broke this test by adding these deprecations is expected? Should I just copy the previous zeros method tree (without deprecations) onto a new function that gets defined in the test and whose sole purpose is this one test?