Expose a public plugin API for extensions

Split out from the v2 RFC (#378, item 2).

Context

External plugins that build on top of this one — most notably
serverless-appsync-simulator — end up re-implementing the parsing and normalization of
AppSync "assets" (resolvers, data sources, mapping templates, pipeline functions, the
resolved config). This duplicates logic that already lives here and drifts out of sync
when the config model changes.

Current state (v2)

The plugin has internal classes (Api, Naming, getAppSyncConfig, the resource
builders) but does not expose a stable, documented API surface for third parties to
consume. There is no supported extension point.

Proposal

Expose a small, stable, documented API that gives external plugins normalized access to
the parsed AppSync configuration and synthesized assets, so extensions can build on it
without copy/pasting internals.

Open questions

• What exactly should be exposed (resolved config? compiled CloudFormation? both?)
• How do we version/stabilize it so internal refactors don't break consumers?
• Where does the boundary sit between "public API" and "internal implementation"?

Feedback welcome — this is a design discussion before any implementation.