Hooks' name are compatible with Dancer1.

Some hooks are implemented in Dancer2 with different names that they use to have
in Dancer1.  Using the `hook_aliases` function, we alias them to their new name.

The documentation is also updated to let the users know that they have different
names now.
Fix documentation for the `before` hook.

This hook receives a Dancer2::Core::Contex object, not a Dancer2::Core::Route.
Move all the hooks' documentation to Dancer2::Manual::Hooks.

This avoid some duplication in the documentation, and it's easier for the
developer to find all the things related to hooks in a single place.
Add the 'on_route_exception' hook.

This hook was implemented in Dancer and is missing in Dancer2.  It's triggered
when an error occurs while executing a route.  It receives as argument the
context adn the error as as string.
Remove documentation for the 'on_handler_exception'.

This hook is not implemented for now, and implementing it will require some
refactoring.
Move errors' hooks to Dancer2::Core::App.

The hooks for errors need to be in the application in order to be executed.
Having them in Dancer2::Core::Error can't work because we never store the
hooks inside this object.
Fix POD error for Dancer2::Manual::Hooks.
Remove multiple definition of `core_debug'.

The function `core_debug' was implemented in three different places, each time
with a slighly different definition.

The only definition we keep is the one in Dancer2, and we don't need to export
it in the DSL, since this sould be used *only* by Dancer2.
When a hook is executed from an app, log the name of the hook.
Dispatcher shouldn't populate error content for internal server error

By populating the Core::Error object for an internal server error
(status 500) with content in the Dispatcher, it was short circuiting
the logic in Core::Error that looks for a puplic/500.html or similar
views template.

Resolves #86.
The request and response are able to (de)serialize data by themeselves.

This change makes the API for the request and response object to be a little
more identical when it comes to (de)serialization of data.

The main addition is the attribute 'serializer' to the Response object.  When
the content is set on this object, it will verify if a serializer is set and
if the data needs to be serialized (e.g.: do we have a ref ?).  If that's the
case the serialization will be done from the object itself, and the dispatcher
does not have to deal with it.

An attribute 'error' is added to the role 'Serializer', where a message is
stored in case of an error while dealing with the data, and a message is
logged.
separating configuration from engines
Create methods to build the various engines.

Since we support only four engines, we can have dedicated methods that
we call and store their values in the attribute 'engines'.

We *should* never store the object in the config, and therefore, everytime
someone need an engine, it should be done via '->engine($name)', and never
via '->settings->{$name}'.

This is still broken.
If there's no logger defined, create one for 'console'.
Don't return undef when a ref is passed to an engine builder.
Get the 'session' from the engines, not the settings.
Inline some code in the `->engine' method and remove a comment.
Get the session from the engines, not the settings.

Also, there's no need to croak if the engine is not set, this is already done
by the ->engine method.
Try to build the session engine correctly.
Merge branch 'devel' into fix/remove-multi-core-debug