Error masking and internals leaking in error handling

There are several places ([`execute_graphql()`](https://github.com/graphql-python/graphql-core/blob/master/graphql/graphql.py#L72), [`complete_value()`](https://github.com/graphql-python/graphql-core/blob/master/graphql/execution/executor.py#L530), [`complete_value_catching_error()`](https://github.com/graphql-python/graphql-core/blob/master/graphql/execution/executor.py#L489), [`resolve_or_error()`](https://github.com/graphql-python/graphql-core/blob/master/graphql/execution/executor.py#L448), [`execute()`](https://github.com/graphql-python/graphql-core/blob/master/graphql/execution/executor.py#L128) [`ExecutionContext.report_error()`](https://github.com/graphql-python/graphql-core/blob/master/graphql/execution/utils.py#L152), may be there is more) where the library indiscriminately catches all exceptions and reports them to client. It's correct behaviour for parsing/usage errors. But for programming and runtime errors there are problems:

- original error is lost and traceback is not reported, so it becomes hard to debug;
- potentially sensitive information is leaked to client via error message.

I believe the the right behaviour would be to catch and report to client specific exceptions only (`GraphQLError` and subclasses?) while propagating the rest.

Related issues:

- [Unable to locate original location of Exception #207](https://github.com/graphql-python/graphql-core/issues/207)
- [Exception traceback disappears when running middleware #208](https://github.com/graphql-python/graphql-core/issues/208)
- [Use exc_info keyword when logging an exception. #165](https://github.com/graphql-python/graphql-core/pull/165)

まず、execute_graphql()、execute()、resolve_or_error()、complete_value_catching_error()、complete_value()、ExecutionContext.report_error() を通じた例外処理を追跡します。関連する traceback と logging の挙動について、リンクされている issue を読み、そのうえで、どの例外がクライアントに報告され、どの例外が伝播し、機密性の高い詳細を公開せずに元の traceback 情報がどのように保持されるかを定義して検証します。

索引モデルが issue の本文から書いたものです。