Accept full JSON number literals in the internal JSON parser

[CharlonTank]

Fixes #108

Problem

lamdera live relays RPC response envelopes through the compiler's internal JSON parser (extra/Lamdera/CLI/Live.hs, D.field "v" D.value). That parser was written for elm.json files and only accepts non negative integers: fractions and exponents raise the dedicated NoFloats parse error, and a leading minus is not recognized at all. As a result, any RPC response containing 42.5 or -5 anywhere fails with rpc response decoding failed for {...} in local dev, while the same endpoint works fine in production.

Minimal repro (integer endpoint works, float and negative endpoints fail): https://github.com/CharlonTank/lamdera-rpc-nofloats-sscce

Fix

Teach compiler/src/Json/Decode.hs full JSON number literals:

• Plain non negative integers keep parsing to the existing Int constructor, byte for byte the same accumulation as before, so every typed decoder used for elm.json (versions, dependency constraints, ...) behaves exactly as it did.
• Numbers with a minus sign, a fraction or an exponent parse to a new Number Data.Scientific AST constructor. Json.Decode.value re-encodes it through the already existing Json.Encode.Number Scientific, so the value round-trips exactly.
• The NoLeadingZeros rule is preserved. Malformed tails like 1. or 2e still error (reusing NoFloats as the error constructor, which avoids touching the public error type).
• All typed decoders (int, bool, string, ...) have wildcard fallbacks, so a fractional number where an int is expected now produces the regular "expecting an INT" decode error instead of a parse failure. No other behavior changes.

Verification

• Built the compiler and reran the SSCCE: all three endpoints now return their exact payloads ({"value":42}, {"value":42.5}, {"value":-5}).
• lamdera make still compiles both the SSCCE app and a production app with roughly 500 modules and a large elm.json, confirming elm.json parsing is unchanged.