Inline fragments are only evaluated against the first subschema containing the merge type

### Issue workflow progress

_Progress of the issue based on the [Contributor Workflow](https://github.com/the-guild-org/Stack/blob/master/CONTRIBUTING.md#a-typical-contributor-workflow)_

- [X] 1. The issue provides a reproduction available on Github, Stackblitz or CodeSandbox
> Make sure to fork this template and run `yarn generate` in the terminal.
>
> Please make sure the GraphQL Tools package versions under `package.json` matches yours.
- [X] 2. A failing test has been provided
- [ ] 3. A local solution has been provided
- [ ] 4. A pull request is pending review

---

**Describe the bug**

See unit tests in PR https://github.com/ardatan/graphql-tools/pull/4965

When we provide the query
```GraphQL
query {
student(id: "12314241") {
id
name
major {
... on MajorSuccess {
id
name
}
... on MajorError {
id
code
}
}
}
```
to the stitched schema, it first executes the Student type against the student subschema. The major type that is returned only contains an ID. The presence of a major ID on its own doesn't give us enough information to pick an inline fragment to evaluate. My understanding is that selecting a fragment is the work of either 1) a provided __typename, an __isTypeOf resolver, or the __resolveType resolver. Regardless of which strategy is used, the type is compared to the inline fragments after the student schema returns its response. The student schema does not have enough information to determine whether the major schema will decide that the type is a MajorSuccess or a MajorError. As such, GraphQL fails to match an inline fragment and determines that the major field is completed. Since the major field is completed, no request to the major schema is made.

**To Reproduce**
Steps to reproduce the behavior:

See unit tests in PR https://github.com/ardatan/graphql-tools/pull/4965

**Expected behavior**
I think I expect the selection set containing the inline fragments to be evaluated by subsequent subgraphs containing merge type definitions for the union type. Although I understand that this might not be supported or that I might be missing a configuration option that enables this behavior.

**Environment:**

- OS:
- `@graphql-tools/...`:
- NodeJS:

**Additional context**

Start with the unit tests referenced in PR #4965 and reproduce the stitched schema scenario described here. Trace how the Student subschema handles the major selection and how subsequent subschemas are considered; done means inline fragments can be evaluated using merge type definitions from later subschemas.

Written by the indexing model from the issue text.