omitempty validation on input fields with/without defaults

[Fazt01]

Fixes #290 and #228 (comment) (for latter, only the comment of mine, not the whole issue)

This is only changing where the omitempty is allowed and forbidden - it does not change where is the omitempty actually generated or not in generated code.

Separately each line of changelog:

• allow omitempty on non-nullable input field, if the field has a default (pretty much InputObject field defaults are ignored/overridden #228 (comment))
  • added a && field.DefaultValue == nil to the "omitempty may only be used on optional arguments" error
• allow omitempty: false on an input field, even when it is non-nullable (# @genqlient(for: "Input.nonOptionalField", omitempty: false) not working #290)
  • fieldDir.Omitempty != nil changed to fieldOptions.GetOmitempty()
• forbid omitempty: false (including implicit behaviour) when using pointer on non-null, no-default input field
  • as setting a correct combination of directives (and potentially some options, which changes implicit pointer and/or omitempty), and this library promises "Compile-time validation of GraphQL queries: never ship an invalid GraphQL query again!", I found it fitting to guard against the most simple case, that can be enforced in Go type system.
  • this, however, is a breaking change, so not sure if I should include it here. No previously present test failed after such change, but for example generate/testdata/errors/DefaultInputsNoOmitPointerForDirective.graphql would previously generate following (below - which has a possibility to send invalid graphql input), but now the generation fails.

       type InputWithDefaults struct {
       	Field         *string `json:"field"`
       	NullableField string  `json:"nullableField"`
       }

• • alternative would be to force omitempty tag in such cases (even if there is no omitempty directive/option) - so that generation would not fail. But I'm not sure if I can afford to do that. That would probably still be breaking change (different generated code for same query), but a bit better. Maybe just setting omitempty flag instead of returning error would be sufficient.

In general, I have also moved the omitempty check from directives to the time of creating Go types/tags of field. This seems more consistent, as not all possibilities were caught before (i.e. general @genqlient(omitemtpy: true) vs @genqlient(for: ..., omitempty: true)). When creating Go type/tags, all the options/directives are already merged, so the final result is being checked. There is minor difference in error message (instead of reference to directive, the error refers to the whole operation, but also includes type.field name)

I have:

• Written a clear PR title and description (above)
• Signed the Khan Academy CLA
• Added tests covering my changes, if applicable
• Included a link to the issue fixed, if applicable
• Included documentation, for new features
• Added an entry to the changelog

[benjaminjkraft]

Man, this code is getting confusing. Anyway your changes seem convincing, and the tests help a lot.

I think the breaking change is a sensible one -- either the query is broken (in which case it's good to reject it) or you effectively always set the value (in which case the fix is simple and a good idea). And it must be rare-ish if none of our tests cover it. If we hear from users we can always adjust!

This should be good to merge once I get confirmation from the CLA person (tomorrow, probably).