feat(API): Add middlewares to falcon API

Currently falcon provides hooks as a way to add logic to all "routed" requests. With this approach it's not possible to execute code when a request is not routed (e.g., method not allowed, path not found ...)
I would like to include the concept of middlewares (same as django) in falcon as it may be useful for many projects. Typical middlewares:
- Generate unique transaction for all requests
- Log all requests and include time ellapsed
- Authentication (imo this should happend before any logic of routing, aka find responder).

A list of Middleware classes can be added to falcon WSGI in this way: 

api.add_middlewares([MiddClass1,MidClass2])

A middleware will be executed always with every request/response dispatched, no matters routing and errors.
A middleware can define process_request or process_response or both; internally the code will be executed when corresponds.
Arguments are the same as hooks and error_handlers. In unit tests, some examples can be seen.

Thanks for coding this up so we could see how it looks. To be honest, now that I see the implementation, I think supporting an exception handler in middleware may not be the best idea, primarily because it makes it harder for users of the framework to reason about the control flow. Also, it feels like we are repeating ourselves by adding an additional error handling mechanism rather than reusing what is already available in the framework.

I've been thinking about this, and I believe the key to a better design is figuring out a good answer to the question of what should be skipped when any one of the various components raises an error. IMHO, if we can provide a fairly simple, predictable control flow for that out of the box, the existing error handling mechanisms (`API.add_error_handler`, `HTTPError`) will be sufficient for the vast majority of cases.

Consider the following call sequence:

```
DiagnosticsMiddleware.process_request
    _
        AuthMiddleware.process_request
            TimerMiddleware.process_request
                FooResource.on_get
            TimerMiddleware.process_response
        _
    ResponseFormatterMiddleware.process_response
DiagnosticsMiddleware.process_response
```

I think what makes the most sense is to only skip the levels below the one that raised the error. That makes it somewhat predictable what will happen, while also allowing for use cases like blocking an unauthorized request but still being able to massage the response into a custom format, log the result, etc. 

For example, if `AuthMiddleware.process_request` were to raise an error in the above call sequence, the error would be used to compose the `resp` object (either by the framework if the error is of type `HTTPError`, or by a custom error handler which itself may either modify `resp` directly or raise an instance of `HTTPError`), and then control would pass to `ResponseFormatterMiddleware.process_response`:

```
DiagnosticsMiddleware.process_request
    _
        AuthMiddleware.process_request
            [skipped]
        _
    ResponseFormatterMiddleware.process_response
DiagnosticsMiddleware.process_response
```

More formally:

```
1. Framework looks up Responder for the request.
2. Framework iterates over each middleware component, calling each component's 
   process_request method in turn
3. Framework calls Responder.
4. Responder performs an operation an operation and puts the result in resp.
5. Framework iterates over each middleware component in reverse order, calling each component's 
   process_response method in turn
6. Framework converts resp to WSGI.
```

```
1a. No responder is available (e.g., in the case of object-based router). In this case, the lookup
    method raises an instance of HTTPError and control passes to step (6).
2a. There is no middleware. Skip to (3).
2b. One of the calls raises an instance of HTTPError. In this case, Framework concerts HTTPError to
    resp, then proceeds as in (5a).
2c. One of the calls raises an error other than HTTPError. If an error handler is registered for the
    raised error type, it is called. Otherwise, Framework re-raises the error to the application, skipping
    any remaining steps. If an error handler is found, however, and calling it raises an instance of
    HTTPError, Framework converts HTTPError to resp, then proceeds as in (5b).
3a. If Responder is wrapped with hooks, those are executed implicitly as part of the call chain. Any
    errors raised are handled as if they were raised by the Responder itself. The one exception to this
    rule is that when an error is raised, Framework executes global after hooks manually. This behavior,
    as well as global hooks in general will be deprecated in version 0.2 and removed completely in 0.3. 
4a. Responder raises an error. Proceed as in (2c).
5a. There is no middleware. Skip to (6).
5b. An error was raised by middleware or a responder. In this case, only process_request methods
    corresponding to the same or higher level of the last successfully-executed process_response method
    are called. 
```

What do you think?