Go 1.18 is out! So we should run tests on it.

Additionally, gqlgen had some issues with it (see 99designs/gqlgen#1961
and golang/go#45584) so I updated that too, which updated some other
things.

Finally, latest gqlgen requires 1.16+, and it's time for us to do the
same anyway, so we can use `embed` and other newer goodies.  So I
dropped running tests for 1.14 and 1.15, and bumped the module language
version.

Test plan: make check

Now that we're on Go 1.16+ we can do this easily! The main advantage is
it means users can build a genqlient binary and use that portably (or we
could distribute one, or whatever). Plus the code is marginally simpler;
the `embed` API is really quite nice.

Fixes #9.

Test plan:
```
make check
go build .
rm -rf generate               # pretend we have no checkout
./genqlient ./internal/integration/genqlient.yaml
./genqlient --init            # fails after generating a default config
```

In 1.16, it's now deprecated and replaced by `io` and `os`.  Let's
upgrade!

Test plan:
- make check
- git grep ioutil

1.42 seems to be having some problems with Go 1.18 (see #2649), so let's
just upgrade to latest.  There was one new error, suggesting to use `%q`
rather than `"%s"`, since the former does escapes properly.  It doesn't
really matter for us -- the string should be an identifier -- but it
doesn't hurt.  (Plus it wanted us to upgrade from ioutil, which I did
in #181.)

Test plan: make check

This enables accessing the Extensions field, as defined in the response
format: https://spec.graphql.org/October2021/#sec-Response-Format

Extensions can be enabled using configuration option use_extensions.
This will change the return parameters of the generated client
functions. Making it a breaking change if enabled.

Since extensions are untyped as defined in the spec, the Client will
return an interface of type map[string]interface{}.

Current implementation always uses POST as the transport mechanism. Adding GET support enables usage of GET queries for caching simply via URL.

Some notes:
- I left the existing API for creating a new client as is, but the implementation could be much cleaner by introducing some sort of configuration struct when creating a new client
- The construction of the query parameters follows the logic from Apollo's client implementation, which can be found here https://github.com/apollographql/apollo-client/blob/8beb4820edc6352996e08f7f73bde3573f1eb666/src/link/http/rewriteURIForGET.ts
- Updated integration tests to use both sets of clients. Updating the tests to use a test suite would be cleaner

This came up in #160, and will surely come up again. I hope the Go
folks figure out something better here, but until such time...

* Allow absolute paths in schema files.

Thsi is useful for some out-of-tree testing I want to do.  It's
unfortunate (imo) that filepath.join doesn't have this behavior by
default.

Test plan:
go test ./...

* run gofmt

* one more change to use pathJoin

GraphQL is pretty restrictive about its identifiers, so for the most
part we can and do safely use GraphQL identifiers in the Go we generate
with attention only to conflicts with other such identifiers. But we do
need to check one thing, which is that the identifier isn't a Go
keyword. (If it is, the generated code will almost certainly fail to
compile, but often with a confusing error message.) In this commit I add
such checks.

The most likely place to run into trouble here is argument names, which
are often one word and are used as-is.  Operation names, if unexported,
can also be keywords, although in practice they're usually multiword.
Field names are always exported, thus safe.  Generated type names are
always prefixed, camel-cased, with the operation name, so they always
contain an uppercase letter (even if the operation name is lowercase),
but type-names specified by `typename` may collide, so we check those.
In theory we could check type-names specified by `bind`, but these must
be defined by the user, so their code will already fail to compile, so I
didn't bother.  I think that's all the places to consider, although it's
hard to be sure.  In summary, we check argument names, operation names,
and user-specified type names.

Test plan: make check

…196)

Some of the errors tests need to have their own schema, so the schema
can do something weird (or even be entirely invalid!).  But most can
still share a schema.  In this commit I have those indeed share a
schema, to avoid having to have a bunch of copies of mostly the same
schema.  While doing so I noticed one error whose location wasn't very
useful, and fixed it.

Test plan: make check

While writing tests at some point I came across an invalid query that
gqlparser doesn't catch, and which causes a panic for us.  Now we
validate for it and return a nice error instead of panicing.

Fixes #176.

Test plan: make check

This implements the approach suggested in
#178 (comment).
See the added documentation for the full behavior.

I didn't realize until today that implementations of GraphQL interfaces
are actually allowed to be covariant: if the interface has a field
`f: T`, then the implementations may have fields `f: U` where `U` is a
subtype of `T` (for example `U` may be an implementation of the
interface `T`, or `U` may be `T!` if `T` is non-nullable. (I thought it
had to be `f: T` exactly.) So I figured I'd add a test and see what
breaks.

Surprisingly, and despite the fact that Go interfaces do *not* allow
covariance, everything... worked? There's at least one place where it's
possible we could ideally use a more specific type [1], but for now I
just wanted to make sure we at least write something that builds and is
vaguely reasonable. Of course I'm not sure if there's anything I've
missed (some day I need to find a fuzzing engine that can fuzz GraphQL).

[1] Specifically, the field
`CovariantInterfaceImplementationRandomItemTopic.Next` might ideally
have type `...NextContentTopic`, not `...NextContent`; we know it's a
topic. This doesn't directly cause covariance problems in Go: the method
`GetNext` still returns `...NextContent` so the interface matches. But
that trick doesn't work for the sibling field `.Related` which is
slice-typed: or rather, we'd need the method to copy the slice to the
correct type. (Not to mention the implemention of any change here would
require a bunch of plumbing because the AST doesn't quite have what we
want.) So it's probably best to just keep this as-is for simplicity and
consistency.

Test plan: make check

GraphQL schemas have some builtin types, like `String`. The spec says
your SDL must not include those, but in practice some schemas do. (This
is probably because introspection must include them, and some tools that
create SDL from introspection don't know they're supposed to filter them
out.) Anyway, we've since #145 had logic to handle this; we just parse
with and without the prelude that defines them and see which works.

The problem is that this makes for very confusing error messages if you
have an invalid schema. (Or if you have a schema that you think is valid
but gqlparser doesn't, which is the more common case in the wild; see
for example #200.) Right now if both ways error we take the
without-prelude error, which if you didn't define the builtins is just
`undefined type String`; if we took the with-prelude error then if you
did define the builtins you'd just get `type String defined twice`. So
we actually have to be smart if we want good error messages for
everyone.

So in this commit we are smart: we check if your schema defines
`String`, and include the prelude only if it does not. To do this I
basically inlined `gqlparser.LoadSchema` (twice), so that in between
parsing and validation we can check if you have `String` and if not add
the prelude. This should in theory be both more efficient (we don't
have to do everything twice) and give better error messages,
although it's a bit more code.

Fixes #175.

Test plan: make check

It feels like just yesterday, but it's been over four months since our
last release! So it's as good a time as any; while there are quite a few
changes they're individually mostly small. As usual, this updates the
changelog, and I'll tag it with the release once it lands.

Test plan: no relevant bug reports lately