Make OffsetArrays a stdlib

[LilithHafner]

I think that it would be nice to have OffsetArrays as a stdlib.

My particular use case that requires it is in sorting. It is sometimes necessary/helpful for performance to have a workspace AbstractVector with the same indices as the input or the region of the input that is to be sorted. For example, radix-sort copies the whole vector back and forth, each time putting it in a slightly more ordered order. A new, faster, QuickSort would do the same. To have any chance of depending on OffsetArrays, OffsetArrays must be a stdlib.

It would be nice to have a unified way of reusing workspaces (e.g. a Vector{UInt8} that sorting methods resize! and reinterpret as needed). When the input is an AbstractVector with offset indices, we could simply construct a workspace with OffsetVector(reinterpret(eltype(input), workspace), firstindex(input)-1).

Without OffsetArrays, this becomes less elegant. Consider, for example, the case when the input is an OffsetArray with negative firstindex. We would need to sort a view into the input that discards the offset indices. This is problematic for two reasons:

1. It is more elegant to support arbitrary indexing wherever possible rather than explicitly convert to one-based indexing
2. views have non-negligible overhead in some of these cases

similar is not sufficient because the workspace must support resizing, should be reinterpretable from a Vector{UInt8}, and should support indices other than the indices of the input (e.g. MergeSort only needs half the size, sorting a Matrix needs much less).

[LilithHafner]

Pairs with #45584 to enable #45570 and #45222

[N5N3]

Can't we just add a simple wrapper in sort.jl which transforms the input offsetvector to a 1-based one? (We only need to cache the firstindex)

[LilithHafner]

Yes. We can do that with view(input, firstindex(input):lastindex(input)). I'll pursue that and report back if I run into performance overhead from those views.

[LilithHafner]

Ick. I don't like stdlibs anymore.