AppSync detached resolvers

It is possible for resolvers to become detached when an incorrect schema is deployed and correcting the schema does not reattach the resolvers. In addition this issue can ripple to affect other resolvers on other fields.

### Reproduction Steps

The most localised reproduction of this can be done with a single field schema and resolver. Given the following schema and API:
Schema:

```graphql
type Query {
ping: String
}
```

API (In CDK):
```python
from aws_cdk import core, aws_appsync

class GraphqlTestStack(core.Stack):
def __init__(self, scope: core.Construct, **kwargs) -> None:
super().__init__(scope, "GraphqlTestStack", **kwargs)

api = aws_appsync.GraphqlApi(
self,
"test_api-",
name="test_api",
schema=aws_appsync.Schema.from_asset("resources/schema.graphql"),
)

api.add_none_data_source("ping").create_resolver(
type_name="Query",
field_name="ping",
request_mapping_template=aws_appsync.MappingTemplate.from_string(
'{"version": "2018-05-29"}'
),
response_mapping_template=aws_appsync.MappingTemplate.from_string(
'$util.toJson("pong")'
),
)
```

If you then deploy this stack it will deploy successfully with a query of `ping` returning `pong`. If you then deploy the following schema you will end up with a resolver that points to nothing:
```graphql
type Query {
}
```
If you then realise your mistake and correct the schema and add the `ping` field back and redeploy, the schema will correct itself and the resolver will be present but the resolver will not be attached and a query to `ping` will return `null`.

### Reproduction Steps (a more sinister presentation)
We can extend the previous example to add three fields to our Query like so:

Schema:

```graphql
type Query {
ping1: String
ping2: String
ping3: String
}
```

API (In CDK):
```python
from aws_cdk import core, aws_appsync

class GraphqlTestStack(core.Stack):
def __init__(self, scope: core.Construct, **kwargs) -> None:
super().__init__(scope, "GraphqlTestStack", **kwargs)

api = aws_appsync.GraphqlApi(
self,
"test_api-",
name="test_api",
schema=aws_appsync.Schema.from_asset("resources/schema.graphql"),
)

api.add_none_data_source("ping1").create_resolver(
type_name="Query",
field_name="ping1",
request_mapping_template=aws_appsync.MappingTemplate.from_string('{"version": "2018-05-29"}'),
response_mapping_template=aws_appsync.MappingTemplate.from_string('$util.toJson("pong1")'),
)
api.add_none_data_source("ping2").create_resolver(
type_name="Query",
field_name="ping2",
request_mapping_template=aws_appsync.MappingTemplate.from_string('{"version": "2018-05-29"}'),
response_mapping_template=aws_appsync.MappingTemplate.from_string('$util.toJson("pong2")'),
)
api.add_none_data_source("ping3").create_resolver(
type_name="Query",
field_name="ping3",
request_mapping_template=aws_appsync.MappingTemplate.from_string('{"version": "2018-05-29"}'),
response_mapping_template=aws_appsync.MappingTemplate.from_string('$util.toJson("pong3")'),
)

```

If you then deploy a broken version of the schema:
```graphql
type Query {
ping1: String
ping2: String this_is_a_typo
ping3: String
}
```
This will successfully deploy however the resulting schema will be empty:

```graphql
type Query {

}
```

If you then correct this mistake and deploy the original schema, the schema will be corrected and all three resolvers will be deployed, however all three will be detached.

---

This is :bug: Bug Report

Start with the CDK resolver definitions and resources/schema.graphql, then reproduce the single-field and three-field deployments against AppSync. Compare resolver attachment state before and after deploying the malformed and corrected schemas; done means the corrected schema restores functioning ping resolvers without detachment spreading to other fields.

Written by the indexing model from the issue text.