Field conflict detection on fragment reuse do not handle sibling bran… (

#2627)

In #2619, code was added to avoid using a named fragment if some
"trimmed" parts of that fragment may have field conflicts with the rest
of the selection (or other trimmed part of other fragment at the same
level). But the logic added is actually not generic enough: because
field conflict validation traverses all fragments, it is not enough
to check a fragment against the selection at the "current" fragment,
we need to check againt every sub-selection that "merges" at the same
level, which may avoid some "sibling" branch of the current one.

To make this easier, the code adds some initial phase to the
`Selection.optimize` method (that try reusing named fragment) which
basically pre-compute the job of collecting the result of the 1st
step of [`FieldsInSetCanMerge`](https://spec.graphql.org/draft/#FieldsInSetCanMerge()).
The code from #2619 is then adapted to use that, thus taking "all
branches" into account regardless of where the recursion of `optimize`
is at.

.changeset/strong-pots-kneel.md

@@ -0,0 +1,6 @@
+---
+
+---
+
+
+