numfmt: reject a leading + and scientific notation to match GNU

[AlejandroCoronadoN]

Problem

numfmt silently accepts inputs that GNU rejects, and prints a wrong value:

$ printf '1e-3\n' | numfmt --from=auto   # prints "1"  (GNU: invalid suffix in input)
$ printf '1e+3\n' | numfmt --from=auto   # prints "1000"
$ printf '+5\n'   | numfmt --from=auto   # prints "5"   (GNU: invalid number)

Rust's i128/f64 parsers accept a leading + and scientific notation, so
these slip through parse_number_part. The E (Exa) suffix is not affected,
because the suffix is stripped before the number is parsed.

Fix

In parse_number_part, reject a leading + and any e/E in the number part,
using GNU's two distinct messages (invalid number for the sign, invalid suffix in input for the exponent).

Verification

Compared against GNU coreutils (gnumfmt) over a matrix of 20 inputs: every
previously-wrong case now matches GNU's exit code (2) and message, and valid
inputs (1K, 2.5M, 100Ki, 1P, 3.5G, -42, ...) are unchanged.

$ printf '1e-3\n' | numfmt --from=auto
numfmt: invalid suffix in input: '1e-3'
$ printf '+5\n' | numfmt --from=auto
numfmt: invalid number: '+5'

Added a regression test; the full test_numfmt suite passes and cargo fmt /
cargo clippy are clean.

[codspeed-hq]

Merging this PR will not alter performance

✅ 347 untouched benchmarks
🆕 10 new benchmarks
⏩ 46 skipped benchmarks¹

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
🆕	Memory	ptx_input_references_short_lines[100000]	N/A	222.2 MB	N/A
🆕	Memory	ptx_long_lines[100]	N/A	29.5 MB	N/A
🆕	Memory	ptx_short_lines[100000]	N/A	240.1 MB	N/A
🆕	Memory	ptx_input_references_long_lines[1000]	N/A	29.1 MB	N/A
🆕	Memory	ptx_tex[10000]	N/A	20.6 MB	N/A
🆕	Simulation	ptx_input_references_short_lines[100000]	N/A	16.2 s	N/A
🆕	Simulation	ptx_long_lines[100]	N/A	1.7 s	N/A
🆕	Simulation	ptx_short_lines[100000]	N/A	14 s	N/A
🆕	Simulation	ptx_input_references_long_lines[1000]	N/A	2 s	N/A
🆕	Simulation	ptx_tex[10000]	N/A	2.9 s	N/A

---

_{Comparing AlejandroCoronadoN:fix-numfmt-scientific-plus (721a00a) with main (66cf72b)²}

Footnotes

1. 46 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on main (e6561b5) during the generation of this report, so 66cf72b was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/tail/inotify-dir-recreate (fails in this run but passes in the 'main' branch)
Congrats! The gnu test tests/cat/splice is no longer failing!
Congrats! The gnu test tests/ls/stat-free-symlinks is no longer failing!
Congrats! The gnu test tests/mv/dir2dir is no longer failing!
Congrats! The gnu test tests/nl/multibyte is no longer failing!
Congrats! The gnu test tests/printf/printf-surprise is now passing!