Ref T5267. Currently, locale definitions can't truly be added in a fully modular way because they aren't free to define their own gender/plural rules.

Allow them to define custom rules. For a small set of popular languages, retain a small performance improvement (this measured as about ~5% for single-parameter strings on my machine). This is optional and just allows languages with simple rules to evaluate very slightly faster with upstream support.

If you load two modules that both define an fr_FR locale (or you define an fr_FR locale, and then we later define one upstream) there will be a conflict, so there still needs to be some upstream/downstream coordination in the long run, but you no longer need to fork or get anything upstreamed to get started. And there are no conflicts with defining a fully-custom locale like en_cloud2butt.

Also inline one idx() call since I was profiling stuff anyway. This was 1-2% faster on my machine.

• Wrote a test script that translated %s thing(s) in a loop, measured performance cost, saw ~5% for letting locales handle these rules themselves, which seems reasonable.
• Measured performance cost of idx(), saw numbers 1-2% better by inlining. This is very micro-optimizey but I think worthwhile in pht() since it's used everywhere and often appears somewhere relatively high up on profiles.
• Ran unit tests, which have reasonable coverage of things like the czech rules.
• Browsed around and looked at strings.