Implement fractional grouping in format specs - #8373

• Closes #xxxx
• This PR follows our AI policy

Summary

RustPython did not support the format spec syntax added in CPython 3.13
that places a grouping option after the precision, so anything of the
form .[digits][,|_] was rejected outright:

>>> format(1234.56789, '.6,f')
ValueError: Invalid format specifier          # CPython: '1234.567,890'

The , was never consumed by parse_precision, so it survived to the
trailing-text check at the end of FormatSpec::_parse.

This implements the option. The integer and fractional parts group
independently and may use different separators, so FormatSpec carries a
separate frac_grouping_option alongside the existing one — the same
split CPython makes with thousands_separators / frac_thousands_separator.

>>> format(1234.56789, '.6,f')      # fraction only
'1234.567,890'
>>> format(1234.56789, ',.6_f')     # both parts, different separators
'1,234.567_890'
>>> format(1.1, '.,f')              # precision omitted, type default applies
'1.100,000'

Parsing follows parse_internal_render_format_spec:
https://github.com/python/cpython/blob/3.14/Python/formatter_unicode.c#L257-L299

• A ,/_ mix is rejected wherever it appears (.,_f, ._,f).
• A repeated separator (.,,f) is deliberately left in the spec. CPython's
  third check does not advance pos, so the leftover reaches the
  trailing-text check and produces a different message than the integer
  part does for ,, — where only one character is left over, it becomes
  the presentation type and the type/separator check reports it instead.
• A dot followed by neither digits nor a separator now raises
  Format specifier missing precision (new FormatSpecError::PrecisionMissing)
  instead of an unrelated error. Previously '{:.}' reported an unknown
  format code and '{:.f}' an invalid specifier.

Rendering groups the fraction digits away from the decimal point, so the
last group may be short and any exponent or percent tail is untouched.
The digit span is located the same way as CPython's parse_number:
https://github.com/python/cpython/blob/3.14/Python/formatter_unicode.c#L488-L516

Two details that are easy to miss:

• The separators count toward the field width, so zero padding of the
  integer part has to reserve room for them, mirroring calc_number_widths:
  https://github.com/python/cpython/blob/3.14/Python/formatter_unicode.c#L604-L606
• 'n' takes its separators from the locale and so cannot carry one:
  https://github.com/python/cpython/blob/3.14/Python/formatter_unicode.c#L361-L367
  The complex locale path rewrites 'n' to 'g' before delegating, so it
  now validates before that rewrite. This also fixes a pre-existing gap:
  format(1+2j, ',n') previously succeeded while format(1234.5, ',n')
  correctly failed.

Test Plan

• Removed @unittest.expectedFailure from tests that now pass
  (2 in test_format, 1 in test_float). The test_float one was not
  targeted; it covers this option extensively, including the zero-padding
  interaction above.

• Added four unit tests in crates/common/src/format.rs covering the
  grouping itself, the untouched tail, the width interaction, and the
  parse errors.

• test_format, test_float, test_complex, test_int, test_fstring,
  test_types, test_str, test_decimal, test_locale, test_string:
  all pass, no unexpected successes.

• Differentially compared against CPython 3.14 over ~900k generated format
  specs (alignment x sign x width/zero x integer separator x precision x
  type, across float/int/str/complex values), against a build of main as
  the baseline: 504,578 cases newly match CPython and none regressed.

  The remaining mismatches are pre-existing and unrelated to this change:
  Invalid format specifier not carrying the spec and object type
  (tracked by test_better_error_message_format), zero-padded complex
  reporting the alignment error instead of the zero-padding one, and a set
  separator with an unsupported presentation type reporting an unknown
  format code rather than Cannot specify ',' with 'j'..

Summary by CodeRabbit

• New Features

  • Added support for grouping fractional digits with commas or underscores in numeric formatting.
  • Fractional grouping works with floating-point and complex values, including width calculations.

• Bug Fixes

  • Improved validation and error messages for incomplete or invalid precision specifications.
  • Fractional grouping is now correctly rejected for locale-aware number formatting.