clarify float min/max behavios for NaNs and signed zeros

[RalfJung]

The first comment is internal, it only documents the intrinsics to more clearly say what they do.
This makes the currently implemented semantics more explicit, so one does not have to go look for the publicly exposed version of the operation to figure out what exactly should happen.

The second commit adds a NaN test to the doc comment for min/max, which matches what we already have for minimum/maximum.

[rustbot]

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

[RalfJung]

Actually I think I misunderstood here -- looking at the 2008 version of the standard, it says

minNum(x, y) is the canonicalized number x if x < y, y if y < x, the canonicalized number if one
operand is a number and the other a quiet NaN. Otherwise it is either x or y, canonicalized (this
means results might differ among implementations). When either x or y is a signalingNaN, then the
result is according to 6.2.

So what we do actually does exactly match IEEE 754-2008 minNum, except for the usual differences in NaN treatment.