[2.0] decoupled service providers

This PR tries to decouple the Silex service providers in order to make them reusable in other contexts like non-web contexts (see #352)

TODO:

 - [ ] update documentation
 - [ ] create the substree-splits (add the `replace` items in the `composer.json` when done)

New Interfaces
----------------------

Two new interfaces are created:

 * `EventListenerProviderInterface`: Event dispatcher listener registration (depends on Pimple and the Symfony EventDispatcher component)

 * `BootableProviderInterface`: Calls specific to Silex Application (mount, before, after, error, ...) (specific to Silex, the web part)

The goal is to keep only what is Silex/Web specific in the boot method.

If we have a look at the service providers after this PR, the only ones with something in their `boot()` method (2 out of 15) are the following:

 * `Monolog`: calls to `before`, `error`, and `after` (everything is related to the Web)
 * `Security`: mounting of the fake firewall routes (web related)

Directory structure for Silex 2.0
---------------------------------

Like Symfony, Silex 2.0 namespaces are organized in sub-namespaces that can be used independently thanks to subtree-splits:

 * `Silex/Api` with all four main interfaces (see below)

 * `Silex/Provider` with all providers (including their dependencies which only depend on Pimple)

 * `Silex/`: everything else (the web part)

The four interfaces are the following:

 * `ServiceProviderInterface`: Service registrations and parameter definitions (only depends on Pimple)

 * `EventListenerProviderInterface`: Event dispatcher listener registration (depends on Pimple and the Symfony EventDispatcher component)

 * `ControllerProviderInterface`: Controller definitions (specific to Silex, the web part)

 * `BootableProviderInterface`: Calls specific to Silex Application (mount, before, after, error, ...) (specific to Silex, the web part)

As these interfaces are in the Api subtree-split, there is no problem in keeping things related to Silex, the web part in the providers themselves -- also because we are talking about a small number of lines of code.