Language migration hands Drupal 7 plural formulas to l10n_pconfig unconverted

Problem/Motivation

Drupal 7 keeps the plural count and the formula of a language in the languages table, the formula as a PHP expression like ($n!=1). 3.0.x keeps one string in the l10n_pconfig third party setting, in gettext form like nplurals=2; plural=(n!=1);, which l10n_pconfig parses for core's plural service and the exporter writes into the Plural-Forms header. The language migration takes the formula from l10n_pconfig's list when it knows the language code and otherwise passes the raw Drupal 7 column through, so any language outside that list ends up with an unparseable setting and invalid exported files. The list also wins over what the site actually used, so a formula an administrator corrected on localize.drupal.org would be replaced. The plugin still carries fixups for an older list format that no longer applies.

Proposed resolution

Build the setting from the Drupal 7 columns whenever they hold a formula (nplurals=N; plural=EXPR; with the $ dropped, which is what the Drupal 7 exporter wrote into its headers for years), use the l10n_pconfig list only for languages without one, and leave the rest uninitialized, which the language pages already report.

Test: new kernel test with a Drupal 7 languages fixture covering a listed language, Polish with its three form expression, a language outside the list, a language without a Drupal 7 formula that the list knows, and one known nowhere, asserting the settings and that core reports the plural counts after the migration.

LLM disclosure

LLM was used to find, diagnose explain and fix this issue. With human review.