Experiment: add unstable RHS type to Ord, impl PartialOrd<[U]> for [T]

[clarfonthey]

This PR adds an unstable Rhs parameter to Ord in an attempt to implement PartialOrd<[U]> for [T] without disrupting specialization. Doing so requires reducing the number of types implementing AlwaysApplicableOrd, which could disrupt specialization, but this (hopefully) won't affect performance.

In particular, *const T, *mut T, and Option<T> no longer are marked as AlwaysApplicableOrd because there is no equivalent implementations of PartialOrd for them. In particular, there are not general implementations of the following, and adding them would be a larger API change than the implementation that was accepted by the ACP:

impl<T, U> PartialOrd<*const U> for *const T {}
impl<T, U> PartialOrd<*mut U> for *mut T {}
impl<T: PartialOrd<U>, U> PartialOrd<Option<U>> for Option<T> {}

Closes #129039, which tracks the implementation of the ACP rust-lang/libs-team#285.

This requires an FCP since it technically adds immediately-stable impls, although it's unclear whether these impls can actually affect users. See below for notes.

r? libs-api

Details

Currently, this expands the following impls:

impl<T: Ord> Ord for &T {}
impl<T: Ord> Ord for &mut T {}

into the following:

impl<T: Ord<U>, U> Ord<&U> for &T {}
impl<T: Ord<U>, U> Ord<&mut U> for &mut T {}

Which is technically a new impl in the sense that for<'a, 'b> Ord<&'a T> for &'b T now exists, although it's unclear whether this actually would be observable by users in practice. The reason for this impl is to ensure that AlwaysApplicableOrd can apply to references, since a PartialOrd implementation exists for them, but it's unclear whether this is truly needed. No matter what, users won't be able to name these specific impls in bounds, but they will be able to use them in functions anonymously by calling Ord::cmp directly.

However, adding this type parameter helps make specialization possible for using Ord on slices whenever possible, since we no longer have to rely on the lifetimes of two parameters being exactly equal to swap in Ord in PartialOrd impls.

Personally, I think that longer-term, it could be useful to have an Rhs type parameter for Ord since it actually makes sense logically, even though it doesn't for Eq (which just adds reflexivity to PartialEq, and thus doesn't depend on the RHS). However, this PR is only adding the type parameter to make PartialOrd work as expected, and that would require its own ACP.

[clarfonthey]

I wasn't entirely sure what the best way to handle these methods was, but since this is guaranteed by impl From<T> for T in the stable case, I figured it was okay.

[clarfonthey]

I should have expected that the standard library tests would be fine but the compiler would absolutely explode.

Will see what I can do about those.

[bors]

☔ The latest upstream changes (presumably #130492) made this pull request unmergeable. Please resolve the merge conflicts.

[alex-semenyuk]

@clarfonthey
Thanks for your contribution
From wg-triage. Any updates on this PR? Could you please rebase