sort: forward fixed-type slice sorting to slices package

[eliben]

The sorting functions in the slices package are generally faster than their equivalents in the sort package. We've added doc comments to the sort package in 1.21 pointing at the faster equivalents, but for now did not modify their implementation. Issues like #60777 show that there could be some rare scenarios where a change would introduce a regression.

In 1.22 we should consider forwarding the implementation of functions like sort.Ints to slices.Sort:

func Ints(x []int) {
  slices.Sort(x)
}

The following functions can be forwarded:

• sort.Ints
• sort.Strings
• sort.Float64s (but we'll need to double check that the FP semantics align, e.g. NaN)
• sort.IntsAreSorted
• sort.StringsAreSorted
• sort.Float64sAreSorted

The other functions in the sort package have slightly different semantics, so it may just be sufficient to retain comments suggesting to consider the slices package instead.

[rsc]

sort.Float64s can call slices.Sort. We defined cmp.Compare the way we did specifically so that the two would match.

[gopherbot]

Change https://go.dev/cl/508135 mentions this issue: sort: forward fixed-type slice sorting to slices package

[eliben]

The attached CL is running into a bootstrapping issue, since the sort package is used in the Go compiler. Our current bootstrap version is 1.17 which doesn't even support generics. slices only makes it into the stdlib in 1.21, and the CL is making sort depend on slices.

According to #54265 we plan to bump the bootstrap version to 1.20 in the 1.22 time frame.

[eliben]

https://go.dev/cl/508135 was updated to work around the bootstrapping issue by using build constraints, per suggestions from @ianlancetaylor and @neild