removed the wrapping of the event for the exception event

It is indeed a good thing to do but for consistency, it must be done for
all events. As this is not possible now, I prefer to revert it for now.
refactored Silex events (refs #503, refs #504, refs #452)

Removed the SilexEvents class. Using the standard Symfony events allows
us to be more flexible (the priorities are the same as the one from
Symfony, so you can hook at any place into the HTTP handling).

Updated documentation to make it accurate with the current behavior, and
extended it to explain the flexibility the developer has.
moved all subscribers registration into the dispatcher closure creation

This removes yet another special case that should not exist. Now, all
listeners/subscribers registration are done in one place.

If you want to disable the exception_handler, you now should call the
disable() method on it. You can still unset it but be careful to do it
as early as possible (which is anyway always the best idea).
moved the locale management to its own event listener

That's ensure that the locale is managed in only one place and always at
the right time.
moved the middleware events to a proper event listener class

That removes the ugly route_*_middlewares_trigger services.
moved the converter and string to response listeners to proper classes
added the application as a third argument to the after middleware (to be consistent with the before one)

This is mainly useful when working with Traits.
moved the before middleware to always be run after the app middlewares
udpated docs

Replaced the term filter by middleware (so now, we have application
middlewares and route middlewares).

Middleware documentation has been moved to its own chapter. This is not
optimal yet as middleware are needed for some part of the usage chapter
(which comes first).
fixed PHP 5.4 warning when a response is an array, dispatch the view event when an error does not return a Response
moved exception wrapper to its own class
refactored the exception wrapper to make the code easier to understand
made a small refactoring for better consistency
fixed CS
moved the modularity section of the docs to its own section
merged branch fabpot/events-refactoring (PR #525)

This PR was merged into the master branch.

Commits
-------

02a3997 moved the modularity section of the docs to its own section
cbc769c fixed CS
d669a7d made a small refactoring for better consistency
deb4238 refactored the exception wrapper to make the code easier to understand
e54627f moved exception wrapper to its own class
5fefc7d fixed PHP 5.4 warning when a response is an array, dispatch the view event when an error does not return a Response
a57f50d udpated docs
8772cbc moved the before middleware to always be run after the app middlewares
63e24c5 added the application as a third argument to the after middleware (to be consistent with the before one)
09a6104 moved the converter and string to response listeners to proper classes
f51a1f2 moved the middleware events to a proper event listener class
3108bfa moved the locale management to its own event listener
ca79d33 moved all subscribers registration into the dispatcher closure creation
056fc32 refactored Silex events (refs #503, refs #504, refs #452)
52a2fda removed the wrapping of the event for the exception event

Discussion
----------

[WIP] Events refactoring

This PR tries to address the issues reported on the `before()` method and more generally, the issues we have with the way we manage events in Silex.

Silex has special events (defined in SilexEvents), and they map with Symfony events. For instance, the `BEFORE` event maps to the `REQUEST` one from Symfony. The main difference is that the priority you set for a `BEFORE` event can only configure the priority compared to other `BEFORE` events; all the events for the `BEFORE` event are dispatched from a single priority on the `REQUEST` event. This behavior removes a lot of flexibility for no reasons. And the same goes for the other Silex events.

So, this PR does is to remove the specific Silex events and replace them with regular Symfony ones. This gives you more flexibility. For instance, it means that now, you can use the `before()` method to do something before the routing (priority `Application::EARLY_EVENT`) or after it (`Application::LATE_EVENT`). And if you really need to do something after the routing and before the security, that's also possible.

The biggest benefit is that with the `before()`, `after()`, `error()`, and `finish()' methods, you can pretty much change all the default Symfony behaviors. So, adding a listener directly to the dispatcher should be now pretty rare.

This PR is not finished yet as the documentation is not updated (but with the added flexibility, it's going to be much easier to document exactly what you can do and how in a consistent manner), but I want to gather feedback on the philosophy first.

---------------------------------------------------------------------------

by fabpot at 2012-11-03T07:56:18Z

I forgot to mention that this breaks BC, but only for edge cases (and this will be documented of course).

---------------------------------------------------------------------------

by yguedidi at 2012-11-03T20:00:35Z

+1

---------------------------------------------------------------------------

by igorw at 2012-11-04T04:34:56Z

I am generally :+1: for this change.

---------------------------------------------------------------------------

by fabpot at 2012-11-04T07:55:04Z

I've added two commits that fix two other issues:

* ca79d33: all subscribers are now registered during the creation of the dispatcher (the exception handler is not a special case anymore)
* 3108bfa: to avoid any problem with the local management, it is now handled in a proper listener that extends the Symfony one.

---------------------------------------------------------------------------

by fabpot at 2012-11-04T08:20:36Z

Another commit (f51a1f2) that moves the middleware management to an event listener (one less ugly hack).

---------------------------------------------------------------------------

by fabpot at 2012-11-04T08:24:19Z

At this point, I want your feedback again about another possible move I'm not sure about.

Now that this PR introduces two event listener classes (`LocaleListener` and `MiddlewareListener`), what about creating two additional ones: one for the controller arguments converter and another one for the StringToResponse handling.

Moving them to proper listeners makes things more consistent (and everything would be registered in the dispatcher creation closure) and more customisable (not sure you ever need to modify the default behavior though).

What do you think?

---------------------------------------------------------------------------

by fabpot at 2012-11-04T08:45:07Z

I've just pushed a commit that implements my previous proposal (09a6104).

---------------------------------------------------------------------------

by igorw at 2012-11-04T15:14:53Z

:+1: moving all of the subscribers out of the application class helps a lot to clean things up.

* `before` and `after` should be more consistent with the `HttpKernelInterface::MASTER_REQUEST` check.
* `error` is still a bit of a mess, if possible I'd move that to a separate class as well.

---------------------------------------------------------------------------

by fabpot at 2012-11-04T15:40:41Z

@igorw: The code in the error method has been moved to its own class (see 77a1878).

What do you mean about the consistency of the master request check?

---------------------------------------------------------------------------

by igorw at 2012-11-04T15:51:29Z

Error refactoring looks good.

The master request check should be return-early in both cases.