Lint for `floating64 as f32` losing the sign of NAN

What it does

Check for any as cast between floats that are not followed by copysign

Advantage

Help libraries that are trying to preserve NAN signage.

From toml-rs/toml#637

I learned recently in rust-lang/miri#3139 that as produces NaN with a nondeterministic sign, and separately that the sign of f64::NAN is not specified (may be a negative NaN). As of rust-lang/rust#116551 Miri has begun intentionally exercising these cases.

This PR fixes places where -nan would incorrectly be deserialized as a positive NaN, nan or +nan would be deserialized as a negative NaN, negative NaN would be serialized as nan, or positive NaN would be serialized as -nan. It adds tests to confirm the expected sign of NaN values, and improves existing tests related to NaN.

Drawbacks

This would be noisy and not apply to most people as they won't care what the sign of NAN is. I'd recommend this be a pedantic lint.

Example

let foo = f32::NAN.copysign(1);  // this is just to avoid the lint for #11717
let foo = foo as f64;

Could be written as:

let foo = f32::NAN.copysign(1);  // this is just to avoid the lint for #11717
let foo = (foo as f64).copysign(if foo.is_sign_positive() { 1.0 } else { -1.0 }]);

The payload names no files or tests; start by tracing Clippy's existing float-cast lint entry points and test patterns. Compare the as cast and copysign examples, and consider the requested pedantic behavior. Done means the lint covers the described NaN-sign cases while allowing the shown sign-preserving form.