Use the freshly stabilized f32::total_cmp methods

[alice-i-cecile]

The FloatOrd type exists to workaround the inability to order Rust floats.

Fortunately, the f32::total_cmp method just stabilized.

We should at least use this internally, and investigate whether we can remove this wrapper type completely.

[DJMcNab]

Luckily, f32 is small enough to test this

But I suspect that total_ord would disagree with the hash implementation.

(We should add a test to loop through all f32s and confirm that Hash's requirements (wrt equality) hold)

[mockersf]

We probably won't be free of FloatOrd as it's used to be generic overt type that impl Ord, which f32 doesn't even with total_cmp.
So this could be just a simplification of the Ord impl for FloatOrd

[nhunds]

I'm new to bevy and open source contribution. Is my understanding right that the only work to do on this Issue is to replace the initial partial_cmp() function call with a total_cmp() call? Or are there any differences in the current implementation and the total_cmp() implementation in the results of the ordering?

[alice-i-cecile]

Is my understanding right that the only work to do on this Issue is to replace the initial partial_cmp() function call with a total_cmp() call

This is the first step. Feel free to open a PR with this change and the reviewers will be able to provide more guidance :)

Like @DJMcNab says though, we should consider testing to ensure that the implementation of PartialEq and Hash still agree, even in pathological edge cases.

[NthTensor]

The same approach taken in #10558 should be used here

• @atlv24 in Migrated to f32::total_cmp() function in FloatOrd::cmp() #5208