Tighter context typing for GraphQLServerOptions

[majelbstoat]

This small patch adds optional support for tighter typing on the context of GraphQLServerOptions, to match the equivalent ones in graphql-tools. There's still a gap as GraphQLSchemaConfig, GraphQLObjectType and getFields are all still typed as any, but it at least allows a demonstration of consistency between the resolvers passed to makeExecutableSchema and the context that will be supplied by parameterising them both with a common type. The param defaults to any and is backwards compatible.

TODO:

• Update CHANGELOG.md with your change (include reference to issue & this PR)
• Make sure all of the significant new logic is covered by tests
• Rebase your changes on master so that they can be merged easily
• Make sure all tests and linter rules pass

/label types

[apollo-cla]

@majelbstoat: Thank you for submitting a pull request! Before we can merge it, you'll need to sign the Meteor Contributor Agreement here: https://contribute.meteor.com/

[abernix]

Sorry, apparently CircleCI wasn't setup to build PRs from Git forks. I think I've fixed it. Could perform either of the following?:

• Push an empty commit to this branch (to be squashed out later):
  git commit --allow-empty -m "empty commit" && git push origin jamie/graphql-option-context; or
• Amend the commit so it gets a new hash, then force push to this PR branch (should be safe, as it's a PR branch!):
  git commit --amend --no-edit && git push --force origin jamie/graphql-option-context

(Both of these assume that your origin remote is https://github.com/majelbstoat/apollo-server).

[abernix]

Thanks so much, @majelbstoat.

[abernix]

This should be published in 1.3.5. Please report back how it works!

[majelbstoat]

Works great, thanks! :)