Fix handling of fragments in handling of Path

Some of the paths returned by the query planner may contain some
"fragment", which are really meant to act as type conditions. That
is, for some data like:
```json
{
  "x": [
    { "__typename": A, "a": 0 },
    { "__typename": B, "a": 1 },
    { "__typename": A, "a": 2 },
  ]
  "y": 42
}
```
and a path `["x", "... on A", "a"]`, then the intend is that this
selects the following data:
```json
{
  "x": [
    { "__typename": A, "a": 0 },
    { "__typename": A, "a": 2 },
  ]
}
```
but skips the `B` entity in particular.

That logic is currently not implemented, and while fragments in path
are parsed, they are otherwise ignored (and so the code currently ends
up selecting the `B` entity).

The only place where such fragments may appear in paths currently
is in deferred nodes, where the paths are used to select what should
be in a particular defer response. I believe (I haven't taken the
time to test it yet) that this mean the code may currently sometimes
include data in a given deferred response that should be sent in a
different response.

This commit fix the code that handles fragments in path so that they
are taken account as explained in the example above.

Unfortunately, this doesn't quite fix the issue with deferred response
mentioned above (it should in some cases, but not all of them) because
the code currently filters responses _before_ it tries to apply those
path selections, which means that in many cases the "__typename" fields
are filtered out and thus cannot be used to decide if an object matches
the path fragment or not (the code thus default to include the object
to mimick the existing behaviour, but this may be incorrect in some
cases).

However, those fragments in path are heavily used in the changes
introduced to the query planner by federation 2.3, so while this patch
does not quite fix the defer issue, it is a step forward and is
necessary in preparation for supporting federation 2.3.