No longer able to catch unexpected errors after removal of UnforgivingExecutionContext

* **What is the current behavior?**
Since the introduction of https://github.com/graphql-python/graphene/pull/1255 by @AlecRosenbaum it was possible to raise unexpected errors to the backend processing, as examplained in https://github.com/graphql-python/graphene/issues/902#issuecomment-672952043. This is critical so you get a decent traceback in the log and no error message for each record in the result set, ie

```json
{
"errors": [
{
"message": "An unknown error occurred.",
"locations": [
{
"line": 5,
"column": 5
}
],
"path": [
"testObject",
0,
"testField"
]
},
{
"message": "An unknown error occurred.",
"locations": [
{
"line": 5,
"column": 5
}
],
"path": [
"testObject",
1,
"testField"
]
}
]
}
```

Changes in graphql-core started to let the UnforgivingExecutionContext tests fail, as recorded by @mweinelt in https://github.com/graphql-python/graphene/issues/1346 and noted by @weilu https://github.com/graphql-python/graphene/pull/1255#issuecomment-857877151 with a suggestion for a potential fix.

https://github.com/graphql-python/graphene/pull/1357 by @codebyaryan brought in welcome changes for query validation, but also removed UnforgivingExecutionContext in https://github.com/graphql-python/graphene/pull/1357#issuecomment-902573578

* **If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem** via
a github repo, https://repl.it or similar.

If we bring back the Test case for UnforgivingExecutionContext without specifying UnforgivingExecutionContext per this configuration https://github.com/alexhafner/graphene/commit/0aaa3fcfac05ae5243d0a65faa562334ae5f37e3, we get those tests failing because unexpected errors are no longer being raised up: https://gist.github.com/alexhafner/5215ef726b356eef6571efb969f6a3e7

* **What is the expected behavior?**

Be able to stop processing a graphql operation when an unexpected error occurs, return a top-level error message to the GraphQL user, and get a full stack trace in the backend to be able to act on the error message further.

For example:

If we bring back UnforgivingExecutionContext, and create a similar solution to the one in https://github.com/graphql-python/graphene/pull/1255#issuecomment-857877151, the tests succeed again as shown here: https://gist.github.com/alexhafner/a78f493f1b869df0ba112b4acb5da5e9. The approach in https://github.com/alexhafner/graphene/commit/f7655378709244a3e24f00605b47056237ff77d9 raises the original errors for non-GraphQL Errors, and handles GraphQL Errors unchanged by using super() on handle_field_error().

other solutions are welcome

* **What is the motivation / use case for changing the behavior?**

catching unexpected issues is system and security critical, and a full stack trace is needed.

* **Please tell us about your environment:**

- Version: graphene master with graphql-core==3.1.6, graphql-relay==3.1.0 graphql-server==3.0.0b4
- Platform: OS X

* **Other information** (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow)
N/A

Commencez par examiner les tests UnforgivingExecutionContext supprimés et les changements des pull requests 1255 et 1357, puis comparez le comportement avec graphql-core==3.1.6. Reproduisez le cas en échec du gist lié. Le travail est considéré comme terminé lorsque les erreurs inattendues qui ne sont pas des erreurs GraphQL arrêtent l’exécution, produisent une seule erreur de niveau supérieur et préservent la stack trace du backend, tandis que les erreurs GraphQL restent inchangées.

Rédigé par le modèle d'indexation à partir du texte de l'issue.