std: Rework std.math.order and std.math.Order

[SeanTUT]

Revival of #23291

• std.math.{order, Order} are now implemented in their own file (std/math/order.zig)
• The values of Order are now explicitly specified
  • To be specific, the values are as follows:
    • lt = -1
    • eq = 0
    • gt = 1
  • Leveraging this enabled some optimizations for Order.invert and Order.compare
• std.math.order is now implemented branchlessly, for both floats and integers
• std.math.order for floats now uses IEEE total ordering
  • That is to say, numbers are ordered as follows: {-nan, -inf, -real, -0, +0, +real, inf, nan}
  • Previously, ordering nans would result in illegal behavior. Now, this is well defined.
  • This is not a breaking change, as it only affects cases which were previously illegal
    • This does have some implications for std.math.order users: 0.0 and -0.0 and no longer treated as equal, in contrast to regular IEEE comparisons, where 0.0 == -0.0
• Additionally fixed std.math.big.int.subCarry returning -0 when subtracting 0 - 0. This had in turn caused some compiler bugs with comptime arithmetic, which made themselves apparent while working on this
  • This bug was why I closed the original PR

[SeanTUT]

As is indicated by the repeated failure of tests, this change is becoming much more involved than it seemed at a glance. I expect to have this finished in a few days.

[SeanTUT]

A follow-up change might be to edit std.sort.{asc, desc} to use the new order, but I will be leaving that be for now

[SeanTUT]

Now that this is (finally, haha) done and in working order, I would like to hear any opinions on the breakage made by total ordering. This only changes how zeros of different signs are ordered, so it is a niche case, but it could be worth considering. Despite that, I think total ordering is the sanest way to go about this; it is a part of the IEEE 754 standard and covers all edge cases.

If we want to eliminate breakage, we could split the current order into order and totalOrder, but that would beg the question of how order would handle nan values, as frankly, illegal behavior doesn't seem like a tenable option here, at least in my opinion (we don't want to cause panics anytime someone tries to do a simple floating point comparison!).