Always deserialize "-nan" as std::f64::NAN

[sunfishcode]

As of #637, "-nan" is deserialized as NAN.copysign(-1). As it's a very recent change, I hope no one is yet depending on this behavior. I'd like to propose changing it to always be NAN.copysign(1.0), or if Rust semantics make the sign bit of the NAN constant deterministic, then just NAN.

This comment appears to be the motivation for the TOML grammar accepting "-nan": to make the grammar slightly simpler. The original idea was that "Of course +nan, nan and -nan would all mean the same thing". Indeed, NaN is literally "not a number", so its sign bit has no inherent meaning. And IEEE 754 itself says "this standard does not interpret the sign of a NaN". It's sometimes possible to locally assign meaning to the sign of a NaN, but such meanings aren't universally shared, in theory or practice, so they're ill-suited for a serialization format such as TOML.

For example, languages like JavaScript have no reasonable way to observe or preserve the sign of NaN. Popular TOML >= 0.5 parsers on npm parse both "nan" and "-nan" into the same JS NaN constant. Consequently, producers of TOML shouldn't assume that consumers are even capable of interpreting the sign bit of NaN.

In Rust, preserving the sign bit on deserialization is possible, however it risks propagating the misconception that the sign bit of NaN has meaning that's interesting to interpret and preserve.

[epage]

See also #640