Add the context parameter to the didEncounterErrors handler

[cuchi]

This change enables us to use the current Context when handling errors via the didEncounterErrors handler.

Consider this scenario, where the Context is relevant to send the user information to an error reporting tool:

class MyErrorHandler extends GraphQLExtension<Context> {

    didEncounterErrors(errors: ReadonlyArray<GraphQLError>, context: Context) {
        for (const error of errors) {
            if (isUnexpected(error)) {
                reportError(error, context.user)
            }
            // ...
        }
    }

}

Fixes #2702

[apollo-cla]

@cuchi: 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]

We're not continuing to develop the graphql-extensions API and we're intending on deprecating it in Apollo Server 3.x with the introduction of the new request pipeline in #1795, which supersedes the previously undocumented graphql-extensions and untested API which was only intended for internal use.

This new request pipeline API (which I might add is strongly typed, unlike its predecessor) already supports this via its (same purpose) didEncounterErrors hook, which receives the context directly (and with a consistent positional parameter pattern, like its sibling hooks):

apollo-server/packages/apollo-server-plugin-base/src/index.ts

Lines 44 to 49 in aa3e23d

	didEncounterErrors?(
	requestContext: WithRequired<
	GraphQLRequestContext<TContext>,
	'metrics' | 'source' | 'errors'
	>,
	): ValueOrPromise<void>;

If there are barriers to you adopting the new request pipeline, please do let us know if you run into any barriers to adopting it! And lastly, I appreciate you taking the time to make a contribution, but opening this PR against a closed issue does run the risk of it not being accepted. I do hope you'll find this solution better, as we think that the new request pipeline API will be a better API in the long-run.