Inconsistent behaviour in \Drupal\filter\FilterFormatInterface::setFilterConfig()

Seemed to cause some test failures.

Root cause:

$editor->getFilterFormat()->setFilterConfig('filter_html', $filter_html_restrictions->merge($fundamental)->getAllowedElements());

in CKEditor 5.

That causes this silly config to be set on filter_html:

Wim Leers → credited hooroomoo → .

IOW: this causes a regression when the view mode ID happens can be cast by PHP to an integer. Arguably we should not do

    $configuration = NestedArray::mergeDeep(
      $this->defaultConfiguration(),
      $configuration
    );

but

    $configuration = NestedArray::mergeDeepArray(
      $this->defaultConfiguration(),
      $configuration,
      TRUE     
    );

(like #3027763: UnroutedUrlAssembler removes query params array item key in buildExternalUrl() → did)

but … this would be:

1. inconsistent with \Drupal\Core\Block\BlockPluginTrait::setConfiguration()
2. this is a contrived example
3. … and nobody seems to have ever complained about the block implementation
4. #2115245: NestedArray::mergeDeep doesn't support preserving integer keys → was closed and marked working as designed

On the other hand … it's thanks to @hooroomoo's attention to detail over at #3245720: [drupalMedia] Support choosing a view mode for → and specifically at https://git.drupalcode.org/project/drupal/-/merge_requests/1796#note_86067 that we even have this all-numeric view mode ID, to explicitly test that the JS works correctly when it receives an all-numeric value!

IOW: without some config generated by PHP code to test a JS edge case, we would not have caught this regression 🤯

Not sure expected but ran the test-only feature and everything passed. https://git.drupalcode.org/issue/drupal-3392978/-/jobs/195657 would of expected a failure?

That's because there's no test yet for the exact test scenario in the issue summary. We probably should add that indeed.