support custom scalars on gql interface

[jasonkuhrt]

Perceived Problem

Curerntly custom scalars are only encoded/decoded when the typed interface
is used. This is a useful feature and users that are using raw but also
have a generated index may want this custom scalar support to extend to
raw usage.

In other words, right now raw assumes that there is never a schema index,
which is not true.

Ideas / Proposed Solution(s)

Given that there is a schema index, we could parse raw input to perform
the same encoding as performed for typed interface input.

Because encoding only needs to deal with arguments that means we only need
to parse and traverse the selection set to discover how variables are used
and thus what they point to in the schema. There would be no need to
re-create the GraphQL document.

Still, for raw requests in particular, it is a cost to have that parsing
take place. Therefore we may want to think about ways to toggle on/off
custom scalar codecs.

It is also a cost for typed requests however it is faster because there is
no parsing step to turn a string selection set into a traversable object.

About Interface-Raw Document Objects versus Interface-Typed Ones

Interestingly, raw can input graphql document object instances, in which
case the perforamnce cost starts to look similar to typed, in that there
is already an object to traverse. The difference is that those objects are
not the same. Graffle'd typed interface does not produce GraphQL
documents. Instead it just builds up its own data types.

This leads me to wonder if the Interface-Typed logic should actually be
building up real docuemnt objects instead of our ad-hoc data. If we did,
we would see these beneifts:

1. We end up having a document builder that can output docuents suitable
   for use in native GraphQL functions. This affords flexibility, is
   simpler internally, is more consistent, is more elegant. For example
   graffle.document(...) would produce something fit to pass to graphql's
   execute function without our custom encoder.
2. No need for our own
   encoder to print interface-typed objects to GraphQL syntax. Note we
   still need an encoder to produce GraphQL docuemnt objects but this
   doesn't involve any string manipulation and thus is simpler.
3. Getting
   back to the feature idea here, we can now support raw-document-object
   encoding for free using the same encoding traversal function.