Feature - Better error and exception handling

This PR improves how Paulus 2 handles exceptions (and low-level errors)... by a lot. Here's how:

- The exception handling code has been abstracted into its own class, instead of being another giant method in the main `Paulus` class.
- Exception handlers are now settable/injectable into the application and are abstracted into generic interfaces, so that the exception handling behavior can be changed very easily. This allows us to handle exceptions in a number of different ways depending on environments, so for example you could print a colorful, interactive, HTML page when a RuntimeException is thrown in dev and silence all other exceptions in production.
- The default implementations of the exception handlers are both informative and BC compatible, giving the developer more information while keeping backwards compatibility
- The entire new structure is based on a dependency injection principle, making testing a lot easier. Now you can even provide a different exception handler when testing! Woot!
- Finally, we now support low-level native PHP error handling. **Finally**
- The new _error_ handler works in a very similar way to the exception handler, being a new generic interface-based injectable implementation into the main Paulus application class.

So yea, I've had this idea for quite a while now and finally had the niche of time to realize it. I hope everyone enjoys the new error handling.

#### Example

Here's an example of the new error handling in a verbose/informative format:

```json
{
  "meta": {
    "status_code": 500,
    "status": "EXCEPTION_THROWN",
    "message": "sick",
    "more_info": {
      "exception_class": "ErrorException",
      "stack_trace": [
        {
          "function": "handleError",
          "class": "Paulus\\Handler\\Error\\BasicErrorHandler",
          "type": "->",
          "args": [
            16384,
            "sick",
            "/srv/www/dev/rican7/src/Api/Api.php",
            259,
            {
              "request": {},
              "response": null,
              "send_response": true,
              "capture": 0
            }
          ]
        },
        {
          "file": "/srv/www/dev/rican7/src/Api/Api.php",
          "line": 259,
          "function": "trigger_error",
          "args": [
            "sick",
            16384
          ]
        },
        {
          "file": "/srv/www/dev/rican7/index.php",
          "line": 13,
          "function": "run",
          "class": "Api\\Api",
          "type": "->",
          "args": []
        }
      ]
    }
  },
  "data": {}
}
```
It isn't in these cases, but I didn't want to violate the interface here and I built the interface for future compatibility with a feature of chaining handlers so if one returns false, it moves to the next handler. That feature isn't dire right now and would require its own PR, but I wanted the interface to be future-compatible.