numfmt: reject an oversized --from-unit/--to-unit instead of panicking

[leeewee]

Fixes #13481.

parse_unit_size computed the unit size as n * multiplier with an unchecked multiplication. A large numeric part with a suffix overflows usize, surfacing as two panics:

• remainder-by-zero (release build): when the product wraps to exactly 0 (e.g. --to-unit=18014398509481984Ki, 2^54 * 1024 = 2^64), the zero unit later reaches integer % to_unit and aborts (exit 134);
• multiply overflow: a merely-huge value (e.g. --from-unit=18446744073709551615K) overflows the multiply itself under overflow-checks, and wraps silently in the default release build.

$ numfmt --to-unit=18014398509481984Ki --to=none 1000
thread 'main' panicked at src/uu/numfmt/src/format.rs:567:8:
attempt to calculate the remainder with a divisor of zero
$ echo $?
134

This uses checked_mul so an out-of-range product falls through to the existing invalid unit size error (exit 1) — matching GNU numfmt, whose unit_to_umax rejects any value that overflows uintmax_t:

$ numfmt --to-unit=18014398509481984Ki --to=none 1000
numfmt: invalid unit size: '18014398509481984Ki'
$ echo $?
1

Extended test_invalid_unit_size with both overflow inputs.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skipping an intermittent issue tests/pr/bounded-memory (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/rm/many-dir-entries-vs-OOM is now being skipped but was previously passing.