Split up the completeValue function

[JeffRMoore]

The completeValue function is fairly large and took me a while to understand. This PR extracts out the logic that is different based on the type of the value being completed. Four new functions are added:

• completeListValue
• completeLeafValue
• completeObjectValue
• completeAbstractValue

The code in each function is identical except i inlined one isAbstractType call to avoid having to add an invariant.

I did add an invariant for an unreachable condition that also exists in the current logic in master, but ends on a return null.

This is a change that I did as part of #304. I'm submitting it as a separate PR. I think its a good change regardless of whether #304 is accepted.

Note that the names in this PR do not match #304. I tried to match the spec more closely with the names here and I will change the other to comply.

The exception to this is using the term leaf to refer to Scalar or Enum, which is established in type/definition.js, but not defined in the spec.

[leebyron]

Thanks so much for the clear process! I'll dig into this.

[leebyron]

Solid work, Jeff! A nice side effect of this that we can now reap is removing the flow type coercions that were within this block of code.

Also, since this reference implementation is designed to mirror the spec - perhaps we should make a similar refactoring to the relevant part of the spec http://facebook.github.io/graphql/#CompleteValue()

[JeffRMoore]

Thanks. I think it would help to split step 5 into step 5 and step 6, one for object, one for abstract type.