Issue title: mergeSchemas not working with Shopify Admin GraphQL schema
 Issue body: <!--**Issue Labels**

While not necessary, you can help organize our issues by labeling this issue when you open it.  To add a label automatically, simply [x] mark the appropriate box below:

- [x] has-reproduction
- [ ] feature
- [ ] docs
- [x] blocking
- [ ] good first issue

To add a label not listed above, simply place `/label another-label-name` on a line by itself.
-->
I'm trying to extend the Shopify Admin GraphQL api with my own endpoints, but as soon as I call `margeSchemas` I get the following error:
```
Failure: Can't find type QueryRoot
```

For now, I'm just passing the shopify schema to the `mergeSchemas` function, yet it does not work.

## Repro

```javascript
const { accessToken, shopName } = event.requestContext.authorizer;

const http = new HttpLink({
  uri: `https://${shopName}.myshopify.com/admin/api/graphql.json`,
  fetch 
});

const link = setContext((request, previousContext) => ({
  headers: {
    "Content-Type": "application/json",
    "X-Shopify-Access-Token": accessToken
  }
})).concat(http);

const executableSchema = makeRemoteExecutableSchema({ schema, link });

const mergedSchema = mergeSchemas({
    schemas: [executableSchema]
});
```

 Comments: 
 Comment 0: I think what might be causing the problem is this part of the Shopify admin graphQL schema:
```graphql
"""
A job corresponds to some long running task that the client should poll for status.
"""
type Job {
  """This indicates if the job is still queued or has been run."""
  done: Boolean!
  id: ID!

  """
  This field will only resolve once the job is done.Can be used to ask for object(s) that have been changed by the job.
  """
  query: QueryRoot
}
```
 Since the field `query` is of type `QueryRoot`, namely the entry point type for queries..
 Comment 1: This is correct.

I have exactly the same issue and initially raised a point on the Shopify Forum.

I have managed to get over this temporarily by doing the following prior to calling makeRemoteExecutableSchema-:

...
    const schema = await introspectSchema(link);

    // Remove the query field from the Job type as this causes issues when merging the schemas
    delete schema['_typeMap']['Job']['_fields'].query;
    return makeRemoteExecutableSchema({
        schema,
        link,
        logger: { log: e => console.log(e) }
    });

 This only affects the Job type and as I currently have no need to inspect the current status of jobs this is not an issue for me.
Every thing else in the Shopify Admin GraphQL Schema is now mergable with all of my other schemas.


 Comment 2: @smcardle  Yes I've found the same work around, but I'm using a schema transformation:

```javascript
transformSchema(executableSchema, [
    new FilterTypes(filter => {
      return filter.toString() !== "Job";
    })
])
```

I hope I won't need to query for jobs any time soon.. Hopefully this issue can be fixed by graphql-tools
 Comment 3: FWIW [here's a simple repro](https://runkit.com/danielrearden/5e6053b528707f0013940fae ). Changing the root type names to the expected defaults (Query and Mutation) resolves the issue. I suspect it's because the names for those types are hardcoded in the source code.
 Comment 4: Working with graphql-tools-fork

https://runkit.com/yaacovcr/mergeschemas-with-custom-root-query-name
 Comment 5: root names still change to default in merged schema, would accept PR to allow new arguments to mergeSchemas to specify.

Should work even when subschemas use different custom root query names
 Comment 6: Fixable in graphql-tools-fork using new RenameRootTypes transform.

See example in:  https://runkit.com/yaacovcr/mergeschemas-with-custom-root-query-name

Note that I changed the original reproduction to use separate DoSomethingPayload and DoSomethingElsePayload types in the two schemas. If you add the { ..., mergeTypes: true } option to mergeSchemas, this is not necessary.

Note also that the way that I believe this works currently is that the gateway shoots off two new root queries to each of the two subschemas, even though it technically already has the data from the first subschema. That is why it works even without the { ..., mergeTypes: true } option. That is easily fixable later by cancelling the proxy even for root types if we already have the data
 Comment 7: Fixed in fork v8.8.1
 Comment 8: Should be fixed in jordankey@example.com. Can anyone check it out?
 Comment 9: Closed by #1307, folded into #1306
{'source': 'GithubIssues', 'repo_name_with_owner': 'apollographql/graphql-tools', 'issue_id': 341785097, 'repo_stars': 2779.0}