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.

The behavior of exception handling has actually been in flux during the development of 0.2. The "old" behavior from the most recent stable release (0.10) can be seen here:

https://github.com/racker/falcon/blob/0.1.10/falcon/api.py#L96

More formally:

**Main Sequence**

```
1. Framework calls wrapped responder.
2. Each *before* hook is executed, in order, while recursing into the call chain.
3. Responder is executed at the bottom of the chain.
4. Each *after* hook is executed, in order, while unwinding back out of the call chain.
5. Framework translates ``resp`` to WSGI.
```

**Variations**

```
2a. No *before* hooks are attached to the responder. In this case, control passes immediately to step (3).
2b. One of the *before* hooks raises an error. In this case, any remaining *before* hooks are skipped, and steps (3) and (4) are skipped as well. Then the error is handled as in (3a) and (3b).
3a. Responder raises an error. Step (4) is skipped, and then if a custom error handler is defined for the raised error type, control is passed to that error handler. If that error handler, in turn, raises an error there are two cases to consider. First, if the error is an instance of HTTPError, it will be handled as in (3b). Second, if the error is any other type, it is not handled by Framework, but is propagated to the WSGI app.
3b. Responder raises an instance of HTTPError. Step (4) is skipped, and then Framework translates the error to `resp` and proceeds as in step (5).
4a. One of the *after* hooks raises an error. In this case, any remaining *after* hooks are skipped. Then, the error is handled as in (3a) and (3b).
```

Someone from the community ran into an issue with the skipping behavior of (2b) and (4a). Specifically, they wanted to be able to do some post processing on their responses (formatting for a custom media type), even when a *before* hook failed (e.g., authentication failed for the request).

So then the current patch was put in place:

https://github.com/racker/falcon/blob/master/falcon/api.py#L113

Unfortunately, as you alluded to, this has its own problems. On the other hand, it is hard to do much better without introducing subtle breaking changes that I'd rather avoid.

With that in mind, I am starting to think that we should backtrack on trying to unify both middleware and global hooks. If we leave the implementation for the global *before* and *after* hooks exactly as-is in master (wrapping the responder methods) for 0.2, and just add middleware as a totally separate feature (both logically and in the code), we have more of a clean slate for middleware behavior, and avoid introducing subtle breaking changes into the way global hooks work. Then, in 0.3, we can remove the global hooks feature. That gives developers a full cycle to migrate to the new middleware model. We can tell everyone that middleware avoids some of the problems with the global hooks model, which should put the migration in a positive light.

What do you think?

P.S. - I'm sorry for the confusion! This feature has a lot of nuances, which has made it really hard to identify the best solution in advance without trying some different approaches. Thanks again for your time and patience!