[rfanth]

Recently, #1346 made the arbitrary precision parser keep -0 as text, but the sign still gets lost in Number, and in i128. This also fixes from_str::<i128>("-0") which currently returns 0, inconsistent with the <i64> version which returns Err.

let v: Value = from_str("-0")?;   // arb_prec (before -> this PR)  |  default build (before -> this PR)
v.as_i64()                        // Some(0) -> None    |  None  -> None
from_value::<Value>(v)?           // 0       -> -0      |  -0.0  -> -0.0
from_str::<i64>("-0")             // Err     -> Err     |  Err   -> Err
from_str::<i128>("-0")            // Ok(0)   -> Err     |  Ok(0) -> Err (now just like from_str::<i64>)

This fixes do_deserialize_i128's own version of the -0 bug, and four places in number.rs that also suffered from it.

All paths changed have tests added that failed before.

Everything is in arbitrary_precision, except do_deserialize_i128, which is shared and changes from_str::<i128>("-0") in both builds to be Err. This now matches from_str::<i64>("-0") which was already Err, fixing a preexisting bug in the process of fixing -0.

Cargo test and pedantic clippy pass.

Discovered while working on TJSON. I had the previous -0 behavior pinned as a known bug in serde_json, and when #1346 patched part of the problem it made tjson-rs's CI fail. Investigating turned up the remaining holes.

[rfanth]

Rebased onto #1355. #1355 made the edit I considered doing here but didn't at first for fear of breaking some longer tagged enums with long decimals, so -0 rather than -0.0 is now possible, and what this PR now produces.

A few tests were slightly changed to check the spelling as well. The PR message and chart were updated to match the current behavior.