Make `ContentRepositoryServiceFactoryInterface` internal, and remove usages in Neos.Neos

[mhsdesign]

Initially it seemed that the ContentRepository should not know much about all things, thus we have the ContentRepositoryServiceFactoryInterface pattern.

That lead to @deprecated really un-nice :D cr services, that will do funny hanstands to get the variation graph or dimension source:

• DimensionControllerInternals.php
• WorkspacesControllerInternals.php
• DimensionsMenuItemsImplementationInternals.php
• FusionExceptionViewInternals.php

The variation graph and dimension source were exposed on the cr via #3906

The question is if we should follow that lead and expose all things on the cr via getters (at least the api stuff)
and maybe have an internal getInternals method for the leftovers from ContentRepositoryServiceFactoryDependencies.

With #4310 the services where also no singletons per cr anymore see removed ContentRepositoryRegistry::$contentRepositoryServiceInstances and by that the buildService pattern has no real gain.

@grebaldi suggested that instead of adding a getInternals to the cr, we could use a custom content repository factory for testing that will expose the dependencies somehow (hole through space) and thus we would be able to fetch them.

Currently we are relying on reflection to get the NodeFactory for example:

neos-development-collection/Neos.ContentRepository.LegacyNodeMigration/Tests/Behavior/Bootstrap/FeatureContext.php

Line 130 in 00a60f3

$propertyConverter = (new \ReflectionClass($nodeFactory))

[bwaidelich]

We have to weight each case. Making InterDimensionalVariationGraph and ContentDimensionSourceInterface available makes sense because they are essential core concepts.

ContentRepository is our single most important API and I would be strongly against adding some getInternals() method to it.
Let's discuss this on concrete examples