The idea is that functions like `zeros` are essentially constructing a
container and filling it with a value. `similar` seems perfectly placed
to construct such a container, so we may accept arbitrary axes in
`zeros` as long as there's a corresponding `similar` method that is
defined for the axes. Packages therefore would only need to define
`similar`, and would get `zeros`/`ones` and `fill` for free. For
example, the following will work after this:
```julia
julia> using StaticArrays

julia> zeros(SOneTo(2), 2)
2×2 Matrix{Float64}:
 0.0  0.0
 0.0  0.0

julia> zeros(SOneTo(2), Base.OneTo(2))
2×2 Matrix{Float64}:
 0.0  0.0
 0.0  0.0
```
Neither of these work on the current master, as `StaticArrays` doesn't
define `zeros` for these combinations, even though it does define
`similar`. One may argue for these methods to be added to
`StaticArrays`, but this seems to be adding redundancy.

The flip side is that `OffsetArrays` defines exactly these methods, so
adding them to `Base` would break precompilation for the package.
However, `OffsetArrays` really shouldn't be defining these methods, as
this is type-piracy. The methods may be version-limited in
`OffsetArrays` if this PR is merged.

On the face of it, `trues` and `falses` should also work similarly, but
currently these seem to be bypassing `similar` and constructing a
`BitArray` explicitly. I have not added the corresponding methods for
these functions, but they may be added as well.