Remove persist flag from container.namespaces service

Convert two additional classes I missed before.

Re #10: Oh, I did not notice that. It seems this is a bit more complicated than I initially thought. Let us try to answer the following questions before proceeding:

1. Should we try to fix the PHP dumper upstream or should we stick with @container.namespaces service?

The method responsible for generating the parameter code is PhpDumper::dumpParameter(). It might be worthwhile not only for Drupal but also for other bigger projects if there was a way to specify whether a parameter value should be inlined (default) or not when dumping the container. The list of non-inlined parameters could be an option to the PhpDumper (least invasive and proper extension point IMHO) or we might try to add that to the ParameterBagInterface (API change, not really the proper extension point because it only would affect the PhpDumper).

I see one problem with adding an option to PhpDumper though. It would also be necessary to somehow build up the list of non-inlined parameters.

Poll question: In order to prevent the regression pointed out by olli in #10, should we...
a) introduce non-inlined parameters in Symfony and use arrays for the namespaces.
b) stick with ArrayObject and optionally try to find a better type-hint.

2. Is it save to revert the changes introduced in #1930020 in the first place?

#1930020: Inject a class into the Core annotated discovery implementation so that namespaces can be updated removed the following todo:

+++ b/core/lib/Drupal/Core/Plugin/Discovery/AnnotatedClassDiscovery.php
@@ -15,40 +15,66 @@
-   *
-   * @todo Figure out how to make the following comment FALSE.
-   *   Drupal modules can be enabled (and therefore, namespaces registered)
-   *   during the lifetime of a plugin manager. Passing $root_namespaces into
-   *   the constructor means plugins in the new namespaces will not be available
-   *   until the next request. Additionally when a namespace is unregistered,
-   *   plugins will not be removed until the next request.
    */

Given that the issue at hand would revert much of #1930020, it seems to me that problem described in the comment should reappear. On the other hand it would be possible that other changes committed in the meantime did resolve the original problem. I assume this was caused by instances of AnnotatedClassDiscovery magically surviving module enable/disable calls (see #6 in #1930020-6: Inject a class into the Core annotated discovery implementation so that namespaces can be updated).

Is it save to revert #1930020: Inject a class into the Core annotated discovery implementation so that namespaces can be updated?
a) Yes, the problem was fixed by issue #...
b) Nope.

Digging into question two, trying to get insight into why this patch returned green. I'll outline changes which I think are relevant on the example of CKEditorPluginManagerTest (see attachment showing the relevant changesets).

1. With #1836008: Remove drupal_classloader() use in Drupal\Core\AnnotatedClassDiscovery it suddenly became necessary to start with a fresh CKEditorPluginManager instance after enabling the ckeditor_test module midways though a test-method. Before the plugin manager always had an up-to-date list of namespaces available from drupal_classloader(). After that change an immutable array of namespaces was injected directly into the constructor of the plugin manager.
2. In the follow-up #1930020: Inject a class into the Core annotated discovery implementation so that namespaces can be updated this problem has been solved by turning the plain array into an ArrayObject and exposing it as a service. Since then the list of available namespaces is updated during kernel rebuilds (initializeKernel). As a result plugin manager instances do not need to be reinstantiated after enabling a module.
4. #2190665: Remove persist flag from services that do not need it reverted this assumption again, and now it seems that test-methods stretching accross container rebuilds are expected that they do not reuse outdated instances

It looks like there was the intention to remove the persist-flag also from the container.namespaces service. But @berdir advised against that just before the patch got in #2190665-24: Remove persist flag from services that do not need it. However, the resulting commit still introduced changes in tests, which only make sense if the persist flag would have been removed entirely.

I think the only reason why #3 passed is because we're lacking test coverage in that area as a result of #2190665.

As discussed with @berdir on IRC, leaving out the API changes and narrowing the scope to just removing the persist flag from the container.namespaces service.

Also we probably need to identify a place to document that it is not save to reuse services across container rebuilds. Note that this is not a new thing introduced by this patch. We just remove one workaround implemented at a time when this fact was not yet understood very well.

Filed #2282371: Document the fact that it is not safe to reuse services across container rebuilds. Given that the API changes are not anymore part of this patch, also removed the tags. From my point of view this is now ready.