Editorial: Define type definitions

This broad change uses definition phrases to define each type, as well as expands the set of sub-sections at the top of the "Types" section which define *kinds* of types. In doing so applies the definitions arrived at in #845 for "wrapped types".

Makes editorial improvements throughout, removing duplicate language or attempting to improve correctness or legibility.

Author: leebyron

spec/Section 2 -- Language.md

@@ -620,7 +620,7 @@ object).
 
 Fragments can be specified on object types, interfaces, and unions.
 
-Selections within fragments only return values when the concrete type of the object
+Selections within fragments only return values when the *concrete Object type*
 it is operating on matches the type of the fragment.
 
 For example in this operation using the Facebook data model:
@@ -1048,14 +1048,14 @@ ObjectValue[Const] :
 
 ObjectField[Const] : Name : Value[?Const]
 
-Input object literal values are unordered lists of keyed input values wrapped in
+Input Object literal values are unordered lists of keyed input values wrapped in
 curly-braces `{ }`. The values of an object literal may be any input value
 literal or variable (ex. `{ name: "Hello world", score: 1.0 }`). We refer to
-literal representation of input objects as "object literals."
+literal representation of Input Objects as "object literals."
 
-**Input object fields are unordered**
+**Input Object fields are unordered**
 
-Input object fields may be provided in any syntactic order and maintain
+Input Object fields may be provided in any syntactic order and maintain
 identical semantic meaning.
 
 These two operations are semantically identical:
@@ -1076,11 +1076,11 @@ These two operations are semantically identical:
 
 ObjectValue : { }
 
-  * Return a new input object value with no fields.
+  * Return a new Input Object value with no fields.
 
 ObjectValue : { ObjectField+ }
 
-  * Let {inputObject} be a new input object value with no fields.
+  * Let {inputObject} be a new Input Object value with no fields.
   * For each {field} in {ObjectField+}
     * Let {name} be {Name} in {field}.
     * Let {value} be the result of evaluating {Value} in {field}.
@@ -1154,9 +1154,8 @@ NonNullType :
   - NamedType !
   - ListType !
 
-GraphQL describes the types of data expected by arguments and variables.
-Input types may be lists of another input type, or a non-null variant of any
-other input type.
+GraphQL describes the *input type* of data expected by arguments and variables,
+and the *output type* of fields.
 
 **Semantics**
 
@@ -1170,13 +1169,14 @@ Type : Name
 Type : [ Type ]
 
   * Let {itemType} be the result of evaluating {Type}
-  * Let {type} be a List type where {itemType} is the contained type.
+  * Let {type} be a *List type* wrapping {itemType} as its *item type*.
   * Return {type}
 
 Type : Type !
 
   * Let {nullableType} be the result of evaluating {Type}
-  * Let {type} be a Non-Null type where {nullableType} is the contained type.
+  * Let {type} be a *Non-Null type* wrapping {nullableType} as its
+    *nullable type*.
   * Return {type}
 
 
@@ -1194,7 +1194,7 @@ behavior in ways field arguments will not suffice, such as conditionally
 including or skipping a field. Directives provide this by describing additional information to the executor.
 
 Directives have a name along with a list of arguments which may accept values
-of any input type.
+of any *input type*.
 
 Directives can be used to describe additional information for types, fields,
 fragments and operations.