Plugins support

[bc-tayvs]

Is your feature request related to a problem? Please describe.
Currently, field descriptions from the GraphQL schema are discarded during code generation, and there is no way to retain or access them. Schema generation tools that use field tags to provide additional context can benefit from keeping the descriptions

Describe the solution you'd like
Introduce a new plugins section in the genqlient.yaml configuration file. This section would allow users to define custom plugins for field tags. Each plugin would specify:

• A name for the tag.
• A path to a shared object file implementing the plugin.

The plugin function should have the following signature (not final):

type PluginInput struct {
	GraphQLName string
	Description string
}

// The function can 
// - return error if something goes wrong. this will stop generation
// - return not Nil result in success case
// - return Nil as a result if the tag should be skipped for provided input
func FieldTagPlugin(input generate.PluginInput) (*string, error) {
  // Implementation.
}

Configuration example:

plugins:
  field_tags: #called field_tags to leave place for other potential plugins
    - name: jsonschema
      path: plugins/jsonschema.so

Describe alternatives you've considered

Additional context
More details about my case.

I have a model generated by the genqclient tool. And I need of schema for it. For this another tool is used, but without descriptions some context is missed. Tool that generates schemas can add descriptions if they store in a particular tag. So i'm trying to connect two tools together.

I already have created and tested a draft PR with the solution: #389

Still need to take care of tests. But some initial review/feedback would be helpful

[bc-tayvs]

Possible other solutions:

• Add an optional config parameter descriptionTag, so the description will be putted there. This solution will be much simpler and will cover most of the cases

[bc-tayvs]

@benjaminjkraft @csilvers @dnerdy @StevenACoffman WDYT?

[benjaminjkraft]

There's a bunch of thoughts on a plugin API in #237. I do think plugins make sense, but I don't want to start adding extension points without care, because they would make it hard to evolve genqlient. Could you take a look at the ideas there and see if they would align to your goals? (I'm fine with starting by implementing just a subset of that proposal, but I'd like to at least keep an eye towards something that will solve for many use cases as I describe there.)

[bc-tayvs]

@benjaminjkraft My original intent for this issue was to introduce a way to generate custom tags for fields. In particular I'm interested in having description stored in a tag. Plugins looked like a good way to make it more customisable and useful for other folks. So I would like to split this issue into two - Descriptions and Plugins

Seeing your plans on plugins support, I start do doubt that my plugin implementation fits well.

What about reshaping this issue to be about exposing descriptions in a tag? We can start with approach that I described in this comment