Add context parameter that passes through the API to resolvers.

[augustoroman]

This adds a net/context.Context parameter that is threaded through from
the calling API to any resolver functions. This allows an application
to provide custom, per-request handling when resolving queries.

For example, when working on App Engine, all interactions with the
datastore require a per-request context. Other examples include
authentication, logging, or auditing of graphql operations.

An alternative that was considered was to use an arbitrary, application-
provided interface{} value -- that is, the application could stick
anything in that field and it would be up to the app to handle it. This
is fairly reasonable, however using context.Context has a few other
advantages:

• It provides a clean way for the graphql execution system to handle
  parallelizing and deadlining/cancelling requests. Doing so would
  provide a consistent API to developers to also hook into such
  operations.
• It fits with a potentially upcoming trend of using context.Context
  for most HTTP handlers.

Going with an arbitrary interface{} now, but later using context.Context
for its other uses as well would result in redundant mechanisms to provide
external (application) metadata to requests.

Another potential alternative is to specifically provide just the
_http.Request pointer. Many libraries do this and use a global,
synchronized map[_http.Request]metadata lookup table. This would satisfy
the AppEngine requirements and provide a minimal mechanism to provide
additional metadata, but the global LUT is clumsy and, again, if
context.Context were later used to manage subprocessing it would provide
a redundant metadata mechanism.

[augustoroman]

Sigh. For some reason, I just didn't see other pull request and ongoing discussion: #25. I'll close this now, but feel free to re-open and/or merge if you like the implementation.