Use a comma as the fr_FR decimal separator

[ckarnell]

fr_FR is the only entry in _DECIMAL_SEPARATOR with a dot. Every other locale there pairs a group separator with a comma, including hu_HU and lv, which group with a space exactly like French does.

humanize.i18n.activate("fr_FR")
humanize.intcomma(1_234_567.89)   # "1 234 567.89", want "1 234 567,89"
humanize.intword(1_000)           # "1.0 mille",    want "1,0 mille"

You already worked this out in #357: the dot came from #248, and merwok said French needs the comma. That PR was closed by its author before it landed. So the value is still there.

One line of data. Plus the 26 fr_FR expectations that encoded the old output.

naturalsize is deliberately untouched, and it is the one loose end. filesize.py never reads the separator, so it still prints 42.0 Ko while intcomma now prints a comma. #357 tried to fix both together and picked up a 10% performance report on the bundle, so this leaves that half alone. Happy to send it separately if you want it, and it's a fair reason to hold this one.

Tests are 789 passing before and after, same set. Reverting just the i18n.py line fails exactly the 26 updated expectations and nothing else, so the tests are pinned to the change, not to the diff.

[Mukller]

Verified locally on the PR branch (Python 3.13): pytest tests/test_i18n.py — 6 passed, including the updated fr_FR assertions for both intcomma (1 234 567,89) and the full naturaldelta matrix (1,0 mille … 1,0 milliard).

The substance is unambiguous: French uses the comma as its decimal separator (per standard French typography and every other locale entry in that same mapping), so "." in _DECIMAL_SEPARATOR["fr_FR"] was simply wrong. This PR aligns fr_FR with de_DE/it_IT/pt_BR/hu_HU rather than introducing anything novel.

One note for the changelog: this changes every fr_FR-formatted decimal output at once — downstream consumers who (incorrectly) parsed humanize's French output against the old dot will see different strings. Worth an explicit line as a behavior fix.

Approving.

[Mukller]

Verified locally on the PR branch (Python 3.13, editable install + all 36 locale catalogs compiled via polib so the i18n suite actually runs):

• pytest tests/test_i18n.py — 80 passed, 0 skipped (without compiled catalogs 74 tests silently skip, which hides regressions in exactly this area — worth noting for the CI setup discussion below).
• Functional spot-checks with fr_FR active:
  • intcomma(1234567.89) → "1 234 567,89" (comma decimal ✓)
  • naturaldelta(1_000_000) → "11 jours"
  • intword(12_400) → "12,4 milles" (decimal comma propagates through intword too)

The change is factually correct — French formats decimals with a comma (unlike the current mapping's "."), and this brings fr_FR in line with every other comma-decimal locale already in _DECIMAL_SEPARATOR.

One CI observation, non-blocking: the project's test workflow appears to run without compiling translation catalogs (my first local pass had 74/80 i18n tests skipped for that exact reason). If CI installs the built package rather than running from source with .mo files present, these tests may be passing vacuously there. Compiling catalogs as a test-setup step would make the suite exercise what it claims to.