Issue #3592951: Let DomainConfigEditContext target the base configuration

Problem

The DomainConfigEditContext seam (#3592832) lets a consumer edit another domain's configuration overrides, but it cannot target the base configuration - the default values every domain inherits unless it has its own per-domain override. Domain 2.0.x offered an "All Domains" option for exactly this; the 3.x seam dropped it.

Solution

Add a BASE sentinel to DomainConfigEditContextInterface:

• setEditingDomain(DomainConfigEditContextInterface::BASE, $names) puts the context into base-configuration mode for the scoped names.
• getDomainId() resolves the sentinel to NULL, so DomainConfigFactory writes the base configuration instead of a domain collection - even when the negotiated domain has a registered override.
• Name scoping, negotiation and the backward-compatibility fallback are unchanged. setEditingDomain() itself needs no change (only NULL clears the context).

The effective model is "behave as if domain_config_ui were not intercepting these config names" - so you get plain core config, which is the base.

Consumer responsibilities (important)

Because getDomainId() resolves to NULL in base mode, domain_config_ui's own hook_form_alter() treats the request as having no editing domain and does not run: it adds neither the enable/disable toggler nor the permission validators. The consumer therefore owns the in-form UI and must gate base editing behind the set default domain configuration permission itself. The UI consumer lives in domain_extras (#3592950).

Tests

Two kernel tests added to DomainConfigEditContextTest:

• testBaseSentinelResolvesToNoDomain() - the sentinel resolves to NULL for scoped names, to the negotiated domain for unscoped names, and clears cleanly.
• testEditableConfigFollowsBaseSentinel() - a save in base mode lands on the base configuration and does not create a per-domain override for the negotiated domain.

Docs

Developer-API docs updated in en/fr/es, including the consumer-responsibilities note above.