Updates documentation to show a side effect of design decision.

When using serializer context groups in JMS serializer, even if just using the Default group in one place explicitly and leaving it blank in another, they will be treated as different component schemas, even though to the serializer outcome they are the same.

Documenting behavior of decision with side effect.

Resources/doc/index.rst

@@ -257,6 +257,28 @@ General PHP objects
     models. Additional information is extracted from the PHP doc block comment,
     but the property types must be specified in the JMS annotations.
     
+    NOTE: If you are using serialization contexts (e.g. Groups) each permutation will be treated as a separate Path. For example if you have the following two variations defined in different places in your code:
+    
+    .. code-block:: php
+        /**
+         * A nested serializer property with no context group
+         *
+         * @JMS\VirtualProperty
+         * @JMS\Type("ArrayCollection<App\Response\ItemResponse>")
+         * @JMS\Since("1.0")
+         *
+         * @return Collection|ItemResponse[]
+         */
+        public function getItems(): Collection|array
+        {
+            return $this->items;
+        }
+
+    .. code-block
+       @OA\Schema(ref=@Model(type="App\Response\ItemResponse", groups=["Default"])),
+
+    It will generate two different component schemas (ItemResponse, ItemResponse2), even though Default and blank are the same. This is by design.
+
     In case you prefer using the `Symfony PropertyInfo component`_ (you
     won't be able to use JMS serialization groups), you can disable JMS serializer
     support in your config: