remove container-related suggestions from docs

docs/disabling_providers.rst

@@ -2,7 +2,7 @@ Disabling the Core Menu Providers
 =================================
 
 To be able to use different menu providers together (the builder-service-based
-one, the container-based one and the convention-based one for instance),
+one, and the convention-based one for instance),
 a chain provider is used. However, it is not used when only one provider
 is enabled to increase performance by getting rid of the wrapping. If you
 don't want to use the built-in providers, you can disable them through the

docs/index.rst

@@ -130,23 +130,22 @@ An example builder class would look like this:
     use App\Entity\Blog;
     use Knp\Menu\FactoryInterface;
     use Knp\Menu\ItemInterface;
-    use Symfony\Component\DependencyInjection\ContainerAwareInterface;
-    use Symfony\Component\DependencyInjection\ContainerAwareTrait;
 
-    final class Builder implements ContainerAwareInterface
+    final class Builder
     {
-        use ContainerAwareTrait;
+        public function __construct(
+            private EntityManagerInterface $em,
+        ) {
+        }
 
         public function mainMenu(FactoryInterface $factory, array $options): ItemInterface
         {
             $menu = $factory->createItem('root');
 
             $menu->addChild('Home', ['route' => 'homepage']);
 
-            // access services from the container!
-            $em = $this->container->get('doctrine')->getManager();
             // findMostRecent and Blog are just imaginary examples
-            $blog = $em->getRepository(Blog::class)->findMostRecent();
+            $blog = $this->em->getRepository(Blog::class)->findMostRecent();
 
             $menu->addChild('Latest Blog Post', [
                 'route' => 'blog_show',
@@ -183,12 +182,6 @@ With the standard ``knp_menu.html.twig`` template and your current page being
         </li>
     </ul>
 
-.. note::
-
-    You only need to implement ``ContainerAwareInterface`` if you need the
-    service container. The more elegant way to handle your dependencies is to
-    inject them in the constructor. If you want to do that, see the method below.
-
 .. note::
 
     The menu builder can be overwritten using the bundle inheritance.

docs/menu_builder_service.rst

@@ -2,12 +2,12 @@ Creating Menu Builders as Services
 ==================================
 
 This bundle gives you a really convenient way to create menus by following
-a convention and - if needed - injecting the entire container.
+a convention.
 
 However, if you want to, you can instead choose to create a service for your
 menu builder. The advantage of this method is that you can inject the exact
-dependencies that your menu builder needs, instead of injecting the entire
-service container. This can lead to code that is more testable and also potentially
+dependencies that your menu builder needs.
+This can lead to code that is more testable and also potentially
 more reusable. The disadvantage is that it needs just a little more setup.
 
 Start by creating a builder for your menu. You can stick as many menus into

docs/menu_service.rst

@@ -13,12 +13,12 @@ Creating Menus as Services
     instead.
 
 This bundle gives you a really convenient way to create menus by following
-a convention and - if needed - injecting the entire container.
+a convention.
 
 However, if you want to, you can instead choose to create a service for your
 menu object. The advantage of this method is that you can inject the exact
-dependencies that your menu needs, instead of injecting the entire service
-container. This can lead to code that is more testable and also potentially
+dependencies that your menu needs.
+This can lead to code that is more testable and also potentially
 more reusable. The disadvantage is that it needs just a little more setup.
 
 Start by creating a builder for your menu. You can stick as many menus into