Issue #3612547: Cache library definitions per domain through the library.discovery service

Core's library.discovery service has been the LibraryDiscoveryCollector itself since Drupal 11.1, when the separate library.discovery.collector service was deprecated; Drupal 12 removed that deprecated service. domain_config decorated the deprecated one, so the per-domain library info cache key was inactive on every core release the 4.x branch supports, and decoration_on_invalid: ignore only hid that on Drupal 12.

The decoration now targets library.discovery, which is the same class with the same constructor on 11.4.x and on main, so one definition serves both lanes and the stopgap is gone.

Also in this change:

• The domain negotiation context is a constructor argument instead of a calls: setter, and the service id becomes domain_config.library.discovery, matching what it decorates.
• New kernel coverage, DomainConfigLibraryDiscoveryTest: the first domain builds its library definitions, the collector writes them to the discovery cache as the needs_destruction tag does at the end of a request, and the second domain must then get its own definitions rather than the entry the first domain wrote. The test module ships a library whose version its hook_library_info_alter() implementation reads from configuration that is overridden per domain.
• Both assertions were checked against unfixed code: with the previous service definition the decoration assertion fails, and with the domain removed from the cache id the second domain reads the first domain's base version.

Verified on Drupal 11.4.4 / PHP 8.4.15: the new class and DomainConfigOverrideEditableTest pass, phpcs with the CI standard is clean over the whole module, and phpstan reports no errors.

Nothing to migrate for a site: no configuration, no schema, no update hook, only cache.discovery entries that rebuild themselves.