Add sort methods to Indexable::Mutable

[straight-shoota]

This patch moves the sort methods from Slice and Array into Indexable::Mutable as suggested in #11057 (comment). It is an alternative to #11057.

All mutable indexables support mutating sort, although the default implementation is not very efficient because it duplicates the collection to a slice for sorting. Array (and Slice obviously) overrides the mutating sort methods to provide a more efficient implementation by directly operating on the buffer. A similar approach can be used for other data types that represent the values in such a way (e.g. StaticArray: #10889).

Non-mutating sort methods are certainly not limited to mutable collections, but mutable collections offer a simple implementation, based on #dup and the mutating sort methods. #dup is not required to be implemented on inheriting types, but it should be pretty common (all Indexable::Mutable types in stdlib implement #dup except StaticArray). So this is a kind of weak dependency, but IMO it's acceptable.
We could consider adding #dup as an abstract def to Indexable::Mutable to make it explicit. But I'm not sure that's really necessary.

Closes #11057

[HertzDevil]

Returning covariant containers from #sort is something that has never been done before in Enumerable or Indexable. It would imply that other methods could be extended to return covariantly this way:

module Indexable::Mutable(T)
  def reverse
    x = dup
    x.reverse!
  end

  def rotate
    x = dup
    x.rotate!
  end

  def shuffle(random)
    x = dup
    x.shuffle!(random)
  end

  def map(& : T -> T) # same return type only
    x = dup
    x.map! { |elem| yield elem }
  end
end

I think this warrants more discussion. For now only the actual mutating methods should be added.

[straight-shoota]

What does "covariant" mean in this context? That we can't assume which type the implementation of #dup returns?

But I agreed that these methods should probably not bei merged like that.

[yxhuvud]

@HertzDevil Those examples may work, but those are pretty inefficient as implementations go as it would force all contents to be streamed through memory twice. Which may be noticable for big containers. That may be ok for O(nlog) operations like sort, but should probably be avoided for operations that are O(n) in any case.

[beta-ziliani]

@HertzDevil care to expand a bit? I don't think I get your comment.

[beta-ziliani]

LGTM. In the future I think it's best to add the dup method somewhere in the hierarchy, although I'm not sure where it should be.

[straight-shoota]

Closing. The main parts were merged in #11254