Add support for abstract-typed named fragments

[benjaminjkraft]

Summary:

In previous commits I added support to genqlient for interfaces,
inline fragments, and, most recently, named fragments of concrete
(object) type. This leaves only named fragments of interface type!
Like other named fragments, these are useful for code-sharing,
especially if you want some code that can handle the same fields of
several different types.

As seems to be inevitable with genqlient, this was mostly pretty
straightforward, although there turned out to be surprisingly many
places we needed to add some handling; almost anywhere that touches
interfaces or named fragments needed some updates. But it's all
hopefully fairly clear code.

As a part of this change I made three semi-related improvements:

1. I refactored the handling of descriptions (i.e. GoDoc), because it
   was getting more and more confusing and duplicative. I'm still not
   sure how much of it it makes sense to inline vs. separate, but I
   think this is better than it was. This resulted in some minor
   changes to descriptions, generally in the direction of making things
   more consistent.
2. I bumped the minimum Go version to 1.14 so we can guarantee support
   for duplicate interface methods. These are useful for
   abstract-in-absstract spreads; we generate an interface for the
   fragment, and (if the fragment-type implements the scope-type) we
   embed it into the interface we generate for its spread-context, and
   if the two have a duplicated field we thus duplicate the method. It
   wouldn't be impossible to support this on 1.13 (maybe just by
   omitting said embed) but it didn't seem worth it. This also removes
   a few special-cases in tests.
3. I added a bunch of code to better format syntax errors in the
   generated code (which we see from gofmt). This is mostly just an
   internal improvement; I wrote it because I got annoyed while hunting
   down a few such errors..

Fixes, at last, #8.

Issue: #8

Test plan:

make check

[dnerdy]

Again, looks great! I found the "comment" and "description" terminology a tad confusing. I left a comment inline with some ideas. Any change would be cosmetic, however, so approving now.

[dnerdy]

I find the current "comment" and "description" terminology a tad confusing. For example, this function returns the struct comment, which comes from the Comment field (if populated), or it generates a "description", which possibly includes the GraphQL description, if one is present.

What do you think about using the term "comment" for the code that generates Go comments, renaming Description to GraphQLDescription, and also renaming Comment to CommentOverride (or something similar)? I'm not quite sure how that jibes with your TODO to include any selection set commit, but I think it reflects how the current code works?

[benjaminjkraft]

Ah, I like CommentOverride, will do!

[csilvers]

(fwiw the commit message says "concrete-typed" when I think it should be "interface-typed")