feat: improve integer parsing performance

[gilescope]

Const functions have improved significantly. Rather than the rough approximation of can_not_overflow that was introduced earlier (#95399), we can be accurate on digits that can lead to the fast path.

There is also a slight specialisation for u128 to improve its parsing performance specifically as we can reduce the u128 multiplications that are done for fewer digits.

(I've done additional fuzz testing on both implementations to ensure there's no regressions. And full disclosure: this PR was designed by Claude and I while I was having a bath yesterday using the /remote-control )

Benchmarks Arm64

Apple M3 Max, ./x bench library/coretests --test-args=from_str, against main. New u128/i128 and long-string benches added in this PR.

38 wins (≥5% faster), 1 regression (≥5% slower), 16 within ±5%. Best −55%, worst +13%.

  Selected wins (≥15%):

  bench_i8_from_str_radix_2          27525 → 12384   −55.0%
  bench_i64_from_str_radix_2         22842 → 11993   −47.5%
  bench_i16_from_str_radix_2         22292 → 11857   −46.8%
  bench_i128_from_str_radix_36       45014 → 27791   −38.3%
  bench_i16_from_str                 28609 → 17713   −38.1%
  bench_i32_from_str_radix_2         19408 → 12095   −37.7%
  bench_i16_from_str_radix_10        28303 → 18160   −35.8%
  bench_u64_from_str_radix_36        27969 → 19613   −29.9%
  bench_i128_from_str_radix_10_long 159379 → 113716  −28.7%    ← long-string
  bench_i128_from_str_radix_2        20049 → 14421   −28.1%
  bench_i64_from_str_radix_10        25465 → 18990   −25.4%
  bench_u128_from_str_radix_10_long 124595 → 102374  −17.8%    ← long-string
  bench_i128_from_str_radix_16       31002 → 25582   −17.5%
  bench_i64_from_str_radix_10_long   97396 → 81480   −16.3%    ← long-string
  bench_u128_from_str_radix_36       30580 → 25816   −15.6%

Sole regression:

  bench_i32_from_str_radix_36        23811 → 26923   +13.1%

The regression is structural - it's always that i32 / radix 36 combo.

Benchmarks x86

On x86_64 (AMD Ryzen 9 5950X): all 55 benches stayed within ±1.5%.
x86 already looks about as optimum as can be.

I've included the results of some additional benchmarks in here _long that exercise the longer path more. I could include them in the PR but one could have too many benchmarks.

That said, if you prefer minimal changes in this PR and just want most of the performance wins, it seems changing #[inline] to #[inline(always)] here will give you most of the perf wins with a one line change:

#[inline(always)]
pub const fn from_ascii_radix(src: &[u8], radix: u32) -> Result<$int_ty, ParseIntError> {

  ┌────────────────────┬──────┬─────────────┬─────────┬─────────────────┐
  │       Option       │ Wins │ Regressions │ i32_r36 │     u16_r2      │
  ├────────────────────┼──────┼─────────────┼─────────┼─────────────────┤
  │ Just inline-always │ 22   │ 2           │ +17.2%  │ +9.8%           │
  ├────────────────────┼──────┼─────────────┼─────────┼─────────────────┤
  │ Full PR            │ 38   │ 1           │ +13.1%  │ +1.1% (noise)   │
  └────────────────────┴──────┴─────────────┴─────────┴─────────────────┘

I'll leave the choice up to you. I guess there must be some compile time cost to executing the const function, but there is an elegance that we have the maximum number hitting the unchecked path as possible.

[ds84182]

bits and is_signed_ty are both compile time constants, and there are only 34 possible radix', so there is a better solution than forcing this to be inlined.

View changes since the review

[gilescope]

I tried, but the perf was worse. We could make the always inline just be for arm or we could close this and accept that at some point arm64 llvm will improve?