Fiber-aware I18n config storage

[lee266]

This PR improves I18n.locale/config behavior in Fiber-based runtimes:

• Thread.current[:i18n_config] is fiber-local, so entering a new Fiber can “lose” locale/config and fall back to default_locale (e.g. CSV/Enumerator creating Fibers).
• A true thread-local (Thread#thread_variable_*) avoids that, but can cause cross-request locale leakage in fiber-per-request servers (e.g. Falcon).

What this PR does

• Use Fiber storage (Fiber[]) when available to preserve locale/config across child Fibers.
• Add Copy-on-Write so writes (e.g. I18n.locale=) don’t mutate shared state: Config#set! freezes the stored config, and setters duplicate as needed before mutating.
• Keep a fallback path for environments without Fiber storage.

I’m still unsure whether i18n should require Ruby 3.2+ (so Fiber storage is always available) or keep supporting older Rubies with the fallback path; feedback welcome.

issue: #723

[lee266]

507a88e needs fix other issues

README.md is same

[ioquatix]

You can use this shim for older Ruby versions: https://rubygems.org/gems/fiber-storage

It doesn't work in C code that creates fibers, e.g. enumerators, but it works for everything else. IOW, you can code to the spec, and users can upgrade Ruby if that is a deal breaker.

[lee266]

@ioquatix
Thanks for the suggestion — this is very helpful.

I’ve updated it to use a Fiber-based approach and to support Ruby >= 3.2, and removed the extra legacy compatibility checks.

Do you think we should also document a workaround path for older Rubies (for example, mentioning fiber-storage as an optional app-level shim), or should we keep the docs focused only on officially supported versions?

[ioquatix]

If it was me personally, I am dropping support for 3.2 at the end of March (it's published EOL for security updates). I simply don't have capacity to maintain backwards compatibility, so I'd suggest you do the same. People can always use old releases. That's my personal philosophy.

[travisbell]

@lee266 @radar Is there anything stopping us from pushing this forward?