Support Merged APIs (`ApiType: MERGED` + `SourceApiAssociation`)

[sid88in]

Feature

AWS AppSync Merged APIs (GA May 2023) compose multiple source GraphQL APIs (their schemas,
data sources, and resolvers) into a single merged API endpoint — useful for multi-team /
multi-service setups.
https://docs.aws.amazon.com/appsync/latest/devguide/merged-api.html

Current state (verified)

The plugin always creates a standard GraphQL API. src/resources/Api.ts never sets ApiType
or MergedApiExecutionRoleArn on the AWS::AppSync::GraphQLApi, and there's no support for
AWS::AppSync::SourceApiAssociation. So neither creating a merged API nor associating a
source API to one is possible.

Proposal (to discuss)

Two distinct capabilities:

1. Declare an API as merged: set ApiType: MERGED and MergedApiExecutionRoleArn on the
   GraphQLApi (CloudFormation supports both). Note AWS's warning: flipping ApiType on an
   existing API forces replacement (new DNS), so this needs care/validation.
2. Associate source APIs: emit AWS::AppSync::SourceApiAssociation
   (MergedApiIdentifier, SourceApiIdentifier, SourceApiAssociationConfig.MergeType =
   AUTO_MERGE | MANUAL_MERGE).

Relationship to existing issues

This is closely related to the long-running "shared API across services / federation" cluster
(#194, #300, #344, #395) and the in-flight apiId multi-stack work (#647). Merged APIs are
arguably the AWS-native answer to a lot of that demand and worth weighing against the apiId
approach. Worth a design discussion before implementation: how much of Merged APIs to model,
and how it interacts with the single-appSync-object config shape.