Plugin API

It seems like one day, maybe soon, we'll find value in a plugin API, so users can hook into codegen in ways that we can't anticipate. This issue is to collect both examples of plugins we might want, and ideas for how to do them.

A few things to think about:
- What hooks do plugins get? a few ideas include rewriting the query in between parsing and codegen, and modifying the types between generating our representations of the Go types and templating them into code.
- How do we specify plugins? Go has a plugin API but actually using it in a nice reproducible way is kind of messy (as we learned at Khan with golangci-lint plugins)
- How do we keep the API as stable as possible? No matter what, this sort of thing is tricky to get right and we'll probably want to set expectations that it won't be super stable early on, but the obvious ways to do things may involve exposing a lot of currently-internal types.

Issues that might be best done via a plugin (please suggest any other use cases you come across):
- #28
- #357
- #27 (doesn't really have to be, but might be better that way)
- #234 (possibly two separate plugins here)
- #265 (and other casing stuff)
- #272
- #332 (if we wanted to add an "add the federation directives to your schema" plugin, not sure if this is useful in practice as such, but something like it might be)
- #390 (adding Go field tags based on the GraphQL schema, if I understand right)

The issue names no files, tests, or entry points; start by reviewing the listed related issues (#28, #357, #27, #234, #265, #272, #332, and #390) and the questions about hooks, plugin specification, and API stability. Done would require an agreed plugin design and scope, rather than a single implementation change.

Written by the indexing model from the issue text.