Issue #3618151: Document and cover the override view maintained by setOverride()

The override object handed out by DomainConfigFactoryOverride::getOverrideEditable() carries two different things, and only one of them was documented anywhere.

initWithData() receives the base configuration merged with the domain's existing override, so $this->data holds what the domain resolves to. setModuleOverride($domain_data) receives the existing override row on its own, so $moduleOverrides answers "which keys does this domain override" — and that is what Config::hasOverrides() and Config::getOriginal() read. set() keeps that answer current as keys change. What actually reaches storage is unrelated: save() recomputes it as the diff against base.

Nothing covered any of it. Before this there was no test in the project calling hasOverrides() and none calling the method that maintains the view; the single getOriginal() call passes $apply_overrides = FALSE. That is why the regression in #3587744, which stopped the method from affecting stored configuration, reached 3.1.0-alpha1 with nothing failing.

Comments. Three described code that no longer exists:

• the pre-merge in getOverrideEditable() was justified by save() copying cast values back onto $moduleOverrides, a path removed by #3587744. The pre-merge is still needed, but because save() diffs against base, so a key missing from $data reads as "back to base" and drops out;
• the comment above the diff in save() recounted how moduleOverrides used to be accumulated and which case the old fallback missed;
• the test class docblock carried the same narrative.

All three now describe the current design.

Coverage. Four kernel tests: a freshly loaded override reports its stored keys, a key set afterwards joins them, a domain with no override reports none, and — the one that keeps the two concepts apart — a key can be reported as overridden on the object and still be absent from storage, because its value equals the base. Each was checked to fail for its own reason: dropping the factory's seeding fails the first, dropping the recording in set() fails the other two.

Visibility. The method is bookkeeping for set() with no other caller in this project, so it becomes protected here and is renamed setModuleOverrideValue(). The old name read as "set a value in this override", which is what set() does, and that misreading is what let the #3587744 regression pass unnoticed. The new name sits beside core's own Config::setModuleOverride() as the single-key variant.

DomainConfigOverrideEditable is not marked @internal and instances are handed to callers through DomainConfigFactoryOverrideInterface, so this is a real API change and 3.x only gets the deprecation. See !437 (merged).

Verified on Drupal 11.4.4: 10 kernel tests in the class, the six pre-existing included.