Fix admin template setters

[wbloszyk]

Subject

This PR will revert some deprecations to allow override Admin templates in old way.
Also override templates by TemplateRegistry::setTemplates() should not replace but override it. People can call it in own code and break application working.

I am targeting this branch, because this change respect BC.

Changelog

### Added
- Added `Sonata\AdminBundle\Templating\MutableTemplateRegistryAwareInterface::setTemplate()`
- Added `Sonata\AdminBundle\Templating\MutableTemplateRegistryAwareInterface::setTemplates()`
### Removed
- Removed deprecations for `Sonata\AdminBundle\Admin\AbstractAdmin::setTemplate()`
- Removed deprecations for `Sonata\AdminBundle\Admin\AbstractAdmin::setTemplates()`

[wbloszyk]

Mybe we can create MutableTemplateRegistry in AbstractAdmin::__constructor() and set templates by setTemplate() and setTemplates() instead creating new services? IMHO setTemplateRegistry() is unnesessery and add some confusing problems like how to set own templates, what is impossible for now.

In master (4.0) we dont use template registry services but take it directly from Admin.

SonataAdminBundle/src/DependencyInjection/Compiler/AddDependencyCallsCompilerPass.php

Lines 403 to 415 in 7e0bdd2

	$templateRegistryId = sprintf('%s.template_registry', $serviceId);
	$templateRegistryDefinition = $container
	->register($templateRegistryId, TemplateRegistry::class)
	->addTag('sonata.admin.template_registry')
	->setPublic(true); // Temporary fix until we can support service locators
	if ($container->getParameter('sonata.admin.configuration.templates') !== $definedTemplates) {
	$templateRegistryDefinition->addArgument($definedTemplates);
	} else {
	$templateRegistryDefinition->addArgument('%sonata.admin.configuration.templates%');
	}
	$definition->addMethodCall('setTemplateRegistry', [new Reference($templateRegistryId)]);

WDYT? @sonata-project/contributors

[wbloszyk]

@sonata-project/contributors @phansys Can we merge it?

[VincentLanglet]

Thanks @wbloszyk

[VincentLanglet]

Mybe we can create MutableTemplateRegistry in AbstractAdmin::__constructor() and set templates by setTemplate() and setTemplates() instead creating new services? IMHO setTemplateRegistry() is unnesessery and add some confusing problems like how to set own templates, what is impossible for now.

In master (4.0) we dont use template registry services but take it directly from Admin.

SonataAdminBundle/src/DependencyInjection/Compiler/AddDependencyCallsCompilerPass.php

Lines 403 to 415 in 7e0bdd2

	$templateRegistryId = sprintf('%s.template_registry', $serviceId);
	$templateRegistryDefinition = $container
	->register($templateRegistryId, TemplateRegistry::class)
	->addTag('sonata.admin.template_registry')
	->setPublic(true); // Temporary fix until we can support service locators
	if ($container->getParameter('sonata.admin.configuration.templates') !== $definedTemplates) {
	$templateRegistryDefinition->addArgument($definedTemplates);
	} else {
	$templateRegistryDefinition->addArgument('%sonata.admin.configuration.templates%');
	}
	$definition->addMethodCall('setTemplateRegistry', [new Reference($templateRegistryId)]);

WDYT? @sonata-project/contributors

Not sure to understand everything and if it's related, but isn't it weird now to have a setTemplate method in both MutableTemplateRegistryAwareInterface and MutableTemplateRegistryInterface ?
I feel like the MutableTemplateRegistryInterface is useless now.

What would be the next @wbloszyk ?

[wbloszyk]

Next step will be add MutableTemplateRegistryAwareInterface::setTemplatesByTemplateRegistry($registry, $override = true). Override false will be use to set global templates by compiler pass which is call after admin service configuration.

In 3.x template registry is created by compiler pass and can not be override(it is possibile but hard to do).

In 4.x template registry will be create by admin constructor. Override template registry will be not allowed but override templates by registry will be easy.

In 5.x I will try to present new templates registry system