Currently, `Base` defines `similar` for `Base.OneTo`, with the
understanding that offset axes will be handled elsewhere. However,
`Base.OneTo` is just one possible one-based range, and there are others
such as `StaticArrays.SOneTo` that exist in the ecosystem. `Base`
doesn't provide a method to handle a combination of different one-based
ranges in `similar`, which leaves the packages in an awkward position:
they need to define methods like
```julia
similar(A::AbstractArray, ::Type{T}, shape::HeterogeneousShapeTuple) where {T} = similar(A, T, homogenize_shape(shape))
```
where `HeterogeneousShapeTuple` is defined as
```julia
Tuple{Vararg{Union{Integer, Base.OneTo, SOneTo}}}
```

https://github.com/JuliaArrays/StaticArrays.jl/blob/07c12450d1b3481dda4b503564ae4a5cb4e27ce4/src/abstractarray.jl#L141-L146
Unfortunately, such methods are borderline type-piracy, as noted in
JuliaArrays/StaticArrays.jl#1248. In
particular, if the narrower `Base` method that handles `Union{Integer,
OneTo}` is removed, then this method explicitly becomes pirating.

A solution to this situation is to have `Base` handle all one-based
ranges, such that arbitrary combinations of one-based ranges hit
fallback methods in `Base`. This PR is a first step in this direction.
We add the abstract type `AbstractOneTo`, and have `OneTo` be its
subtype. We also add methods to `similar` and `reshape` that accept
`AbstractOneTo` arguments. This makes it unnecessary for packages to
dispatch on awkward combinations of `Union{Integer, OneTo}` and custom
one-based axes, as the base implementation would handle such cases
already.

There may be other methods that accept an `AbstractOneTo` instead of a
`OneTo`, but these may be addressed in separate PRs. Also, there may be
one-based ranges that can't subtype `AbstractOneTo`, and a full solution
that accepts such ranges as well needs to be implemented through a
trait. This may also be handled in a separate PR.

---------

Co-authored-by: Tim Holy <[email protected]>