Ambiguous use of "Type"; propose new "InputType" production

[Variable Definitions](https://facebook.github.io/graphql/June2018/#VariableDefinitions) has the following production:
```
Variable : $ Name

VariableDefinitions : ( VariableDefinition+ )

VariableDefinition : Variable : Type DefaultValue? Directives[Const]?

DefaultValue : = Value[Const]
```
where _Type_ has the following production:
```
Type :

NamedType
ListType
NonNullType
NamedType : Name

ListType : [ Type ]

NonNullType :

NamedType !
ListType !
```
where _Name_ reduces to an arbitrary string of specified character set.

This _Type_ production introduces ambiguity to the [implementation](https://github.com/facebook/graphql/blob/master/spec/Section%203%20--%20Type%20System.md#input-and-output-types) of `IsInputType(type)` which is used in [CoerceVariableValues](https://facebook.github.io/graphql/June2018/#CoerceVariableValues()) which specifies that Input type must be one of _Scalar_, _Enum_, or _Input Object_, or one of those types successively wrapped in _NonNull_ or _List_. _Name_ however can be any arbitrary string, not just derivative of one of those 5 types.

Additionally we know _Arguments_ which may be satisfied by _Variable_(s) defined in _VariableDefinitions_ are the following
```
Arguments[Const] : ( Argument[?Const]+ )
Argument[Const] : Name : Value[?Const]
```
where _Value_'s production is:
```
Value[Const] :
[~Const] Variable
IntValue
FloatValue
StringValue
BooleanValue
NullValue
EnumValue
ListValue[?Const]
ObjectValue[?Const]
```
It would appear then that the _Type_ defined for a _VariableDefinition_ may be better suited as being defined as the types of _Value_ (minus _Variable_):
```
InputType:
Int
Float
String
Boolean
Null
Enum
List
InputObjectType
```
where
```
InputObjectType: Name

// some comment about this Name being that of an InputObjectType
```

Now that there's no ambiguity `IsInputType` can be adjusted to use exhaustive pattern matching in languages that support it. Matching `List | Null` is recursive. Matching Scalar and Enum types returns `true` and matching `InputObjectType Name` then confirms that `Name` is indeed an `InputObject` in the Schema.

`Name` could subsume the entire production as it's currently doing, however, I think this extra production more closely matches the semantics, is clearer to the reader, and as just stated is safer for languages which support exhaustive pattern matching.

If this seems reasonable I'd be happy to open a PR to make the adjustment.