Avoid parse ambiguity on types & extensions

[leebyron]

Partial fix to #564, adds lookahead constraints to type system extensions to remove ambiguity or inefficiency from the grammar.

The GraphQL grammar should be parsed in linear type with at most one lookahead. Since extensions have an optional { } body, finding the token { should always attempt to parse the relevant portion of the type extension rather than completing the type extension and attempting to parse the query shorthand SelectionSet.

[IvanGoncharov]

@leebyron I think it's the best solution that possible without breaking changes.

P.S. In retrospective, legacy SDL syntax that always requires curly braces (even if empty) offered a better solution to this problem:
https://github.com/graphql/graphql-js/blob/670bbaca5ed897d0ee2caadbc8ac3a0bbf281b87/src/language/parser.js#L73-L81

[leebyron]

P.S. In retrospective, legacy SDL syntax that always requires curly braces (even if empty) offered a better solution to this problem

Yeah, I agree. I believe I made a mistake with that change for type definitions.

[leebyron]

Updated this change to use a single token lookahead since that's more accurate to how we expect parser implementations to implement this restriction, and it reinforces the idea that parsing should be linear time.

Also includes both type extensions and type definitions, and updates the grammar appendix

[leebyron]

Here's a parser test case:

interface Foo

{ alpha: beta }

Before this change, this could be interpreted either as:

1. An incompletely defined interface Foo interface Foo followed by a query shorthand querying the field "beta" with the alias "alpha" { alpha: beta }
2. An interface "Foo" with a single field "alpha" of type "beta" interface Foo { alpha: beta }

After this change, option 2. is the only legal result. 1. is not possible since the incompletely defined interface must not be followed by {.