This PR starts to try and solve #26438. For now it's just a WIP with the reproducing test case.

The bug is present when:

• a third party error handler (like Sentry) is installed
• a fatal in thrown under PHP 7

The third party error/exception handlers remember the previous handler, and call them when their work is finished. But Symfony's handler has this piece of code:

Citing @alcohol from #26438:

it looks like it is trying to find itself (or an instance of) in the stack of exception handlers that may or may not have been registered. It does this by restoring previous error handlers, and looking at what gets restored. Once it finds itself (or there simply arent any), it "restores" the previous stack of error handlers by reassigning them in order, and proceeds to the setExceptionHandler step, where the $handler should be an instance of itself, and $h is whatever what was last added to the stack of error handlers.

This operation creates a loop because the handler is altering the order of exception handlers, generating a loop: Symfony's handler is normally registered first by the FrameworkBundle, so it's putting himself as the last one registered with that.

Pinging @nicolas-grekas since he seems to have wrote a great part of the ErrorHandler.