Fix signed zero bugs & refine numeric restrictions

[kpreid]

Problem

There's a correctness bug lurking in our use of ordered_float::NotNan: positive and negative zero, -0.0 and 0.0, compare equal, and this can cause different outcomes of further operations (notably division or reciprocal). This means that using them as cache keys is invalid except where the sign is known to make no difference.

Closely related, but not strictly a bug: there are cases where NotNan is less restrictive than we would benefit from; for example, Rgba allows an alpha less than 0 or greater than 1, but this is meaningless.

Solution

All of our uses of NotNan (we don't have any uses that aren't for cache-key/change-detection purposes, I believe) should be replaced with wrappers that are either more restrictive or consider positive and negative zero distinct, as is appropriate for the application.

If some of the resulting wrappers seem more generally applicable, it might make sense to contribute them back to ordered_float.

[kpreid]

Commit 20cd9d6 replaces all uses of NotNan within color types with the new numeric wrapper PositiveSign.

Next steps:

• There's a lot of places where what is needed is a 0-1 restricted type: alpha, reflectance RGB, bloom intensity option, progress bar fill. I haven’t thought of a good name for it.
• Replace NotNan with PositiveSign in uses like the view distance in graphics options. (That’s separately clamped to a nonzero minimum value, so it's not strictly required, but we might as well.)

[kpreid]

As of commit ef1a45e, there is a ZeroOne type, and it is used by Rgba for alpha and GraphicsOptions for bloom blending.

[kpreid]

As of commit 30ceaed, GraphicsOptions no longer uses NotNan.

[kpreid]

Remaining non-incidental uses of NotNan:

• Points/vectors (can't be PositiveSign since they can be negative):
  • Spawn::eye_position
  • Spawn::look_direction
  • SpacePhysics::gravity
• Fluff::BlockImpact::velocity (can be PositiveSign)
  (update: done in commit e6eb4a2)
• FpsCounter::average_frame_time_seconds (can be PositiveSign)
  (update: done in commit fc3f723)
• Conversion methods on color types

[kpreid]

Whoops, the design of PositiveSign is not consistent. In FP arithmetic, 0.0 * INFINITY is NaN, so as long as PositiveSign includes INFINITY, it isn’t closed under multiplication.

My first thought is to define multiplication such that 0.0 * INFINITY == 0.0, because in the actual applications for PositiveSign, positive infinity should almost always appear only as essentially “would be finite but it is too large to be represented” — we don’t generally get an infinity correctly from a division by zero. That would make PositiveSign no longer merely a restriction, but it might be the least bad thing to do. Redefining arithmetic should be done with care, though.

[kpreid]

Implemented 0.0 * INFINITY == 0.0 in b24f917.