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.

It would be great to also have a test that checks that the middleware is executed in a specific order (and this should be documented in the class docstring for API). Take the case of the RequestTimeMiddleware. You would want the start and stop times to be taken at the same scope. For example, if I only want to time how long the actual responder method in the resource class takes, I would place `RequestTimeMiddleware()` last in the list (as done here), and then expect the following execution order:

```
TransactionIdMiddleware: process_request
    RequestTimeMiddleware: process_request
        MiddlwareClasResource: on_get
    RequestTimeMiddleware: process_response
TransactionIdMiddleware: process_response
```

I believe that the way the code is written now, what you have instead is the following, which will cause the stop time to be measured later than it should be.

```
TransactionIdMiddleware: process_request
    RequestTimeMiddleware: process_request
        MiddlwareClasResource: on_get
    TransactionIdMiddleware: process_response
RequestTimeMiddleware: process_response
```

This would only apply to the new notion of middleware; the deprecated "after" hooks should still continue to run in the order specified, to ensure backwards-compatibility. In 0.1 the developer was responsible for explicitly defining the order in which hooks would run:

```python

class TimerHook(object):
    def before(self);
        self.start_ts = time.time()

    def after(self):
        self.stop_ts = time.time()

timer = TimerHook()

api = falcon.API(before=[auth, timer.before], after=[timer.after, do_something_else])
```

However, when using the new `middleware=[...]` feature, the order of the "after" methods is no longer customizable, and so we will just have to pick what we think makes the most sense for 99% of the use cases.

What do you think?