Status code handler.

[arteymix]

The status handler is invoked with perform_routing, so next can be used to jump
to the next status handler for a given status. If nothing matches, the router
handler is used.

The great thing about this implementation is that it reuses perform_routing and fallbacks on Router default handling if a status is not handled.

[arteymix]

It requires some tests to cover the following cases:

• status is registered
• status is registered and handler invoke next (should trigger the next handler in queue)
• status is not registered (fallbacks on Router default handling)

It might have to be rebased on 0.2/end-in-a-continuation it the latter get merged before.

[arteymix]

We need a way to obtain the error message, probably through Request.params.

[arteymix]

Maybe it would be a good thing to set the status code before invoking the handler.

The default handling would only be for specific exceptions.

[arteymix]

One important thing to document is the capability for status handler to change the thrown Error.

A status handler can turn a Redirection into a ClientError.NOT_FOUND, which could be useful to cancel the effect of a thrown status.

[arteymix]

Setting the status code is not a good thing and will cause problems if another Error is thrown during the status handling.

Moreover, the response should be in the exact same state it was when the exception was thrown.

[arteymix]

Using the request parameters can have the dangerous side-effect of overwritting existing keys in the parameters.

However, it does matter only if the original code or message value is desired during the status handling, which is not highly probable.

[arteymix]

Merged directly into master.