Config schema parsed from one release is not kept for parsing other releases

Problem/Motivation

potx resolves the types in a module's config schema through the schema of core and of the modules it depends on. Those live in other releases, parsed at other times. Drupal 7 keeps what potx learns in two tables (l10n_drupal_parsed_module_data, l10n_drupal_schema_reverse_lookup) through the potx callbacks, so a contrib release parsed on its own still knows that core's label type is translatable, and which module owns the schema of a config/optional file.

3.0.x calls potx_local_init() with the extraction directory under /tmp instead. Those callbacks are meant for drush runs inside a Drupal checkout and look for sibling modules through /core/, /modules/ and /sites/ in the path, which a temporary directory has none of. So potx knows nothing beyond the tarball being parsed, and forgets it after the run. Any config/install value typed label, text or another core-defined translatable type in a contrib release is not extracted, and config/optional files are skipped, so these strings never reach translators.

Proposed resolution

Add a schema store service to l10n_server with the two tables (l10n_server_parsed_module_data, l10n_server_schema_reverse_lookup, JSON columns instead of the Drupal 7 serialized ones), implement the six potx callbacks on it, and have the parser service register them instead of calling potx_local_init(). No update path, 3.0.x sites are new installs.

Covered by a Drupal 7 test (L10nDrupalSchemaStoreTestCase) and its port SchemaStoreTest in the l10n_drupal_rest kernel tests, with the same fixtures: a package with core's data type schema, a provider module defining a config schema, and a consumer module shipping config/install and config/optional files that rely on both. Parsed first, the consumer yields no config strings; after core and the provider are parsed, parsing it again yields them from the stored schema. The port fails before the change.

The Drupal 7 test needed one line in _l10n_drupal_schema_load(): unserialize() of a NULL column is a PHP 8.1 deprecation, which the test runner reports as an exception.

Data model changes

Two new tables in l10n_server, matching the Drupal 7 ones: parsed module data (module name, dependencies, processed schema) and the schema key to module reverse lookup.

LLM disclosure

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