Full and none-intrusive exception hook.

# Intro
My goal is as follows, To be alerted of all uncaught exceptions thrown in the notebook. Whilst;
- Getting full information; both the exception as well as the traceback.
- Without impacting the flow of the notebook, other hooks into Ipython should still apply and the shown error message shouldn't change.

# Why would you want this?
There are more and more systems and tools that encapsulate Ipython notebooks for production critical work. This happens with varying quality in error handling and monitoring. This minor change would provide organizations with the tools to create a standardized layer of IPython monitoring that works across tools and notebook types.

# Current status
Currently, there are, to my knowledge, two ways to consistently get exceptions anywhere from an IPython based notebook. One doesn't provide full context, the other is very intrusive. I do however think that I have a very minor change that will make this possible.

The first approach is via `get_ipython().set_custom_exc(...)` this provides both the exception as well as the traceback. In other words, this approach provides full information. This approach has two major issues however;
1. There can only be one handler of this type
2. It massively impacts the way Jupiter notebooks are executed; exceptions are not propagated in the way they usually are after the handler is called.

The second approach is to register an `post_run_cell` handler using`get_ipython().events.register` however the result (`ExecutionResult`) that is send to the registered handler doesn't contain the traceback of the exception (which is returned).

# My suggestion for a solution.
I'd suggest to slightly modify `InteractiveShell._run_cell`. For context, the last few lines of this function are:

```py
except BaseException as e:
info = ExecutionInfo(raw_cell, store_history, silent, shell_futures)
result = ExecutionResult(info)
result.error_in_exec = e
self.showtraceback(running_compiled_code=True)
return result
return
```

It would be very easy to either create a new class `ExcecutionExceptionResult(ExecutionResult)` which also contains a traceback field or simply add a traceback field to ExcecutionResult (we could call it `traceback_when_error` if we want to be super explicit).

As you can see from the code snippet above, this should be a very minor change with a huge impact on this use case.