[WIP][EventDispatcher] Allow per tag EventDispatcher in RegisterListenersPass

| Q             | A
| ------------- | ---
| Bug fix?      | no
| New feature?  | yes
| BC breaks?    | no
| Deprecations? | yes
| Tests pass?   | yes
| Fixed tickets | N/A
| License       | MIT
| Doc PR        | symfony/symfony-docs#3425

- [x] submit changes to the documentation

In HttpKernel, the main purpose of this CompilerPass was to register Kernel listeners. However, in EventDispatcher, it could be used to register Events on any EventDispatcher Service (or anything quacking like it, I'm not enforcing the interface check, on purpose but if you prefer, it's so easy to do...).

Since the RegisterListenersPass is now in EventDispatcher, I think it could be useful to allow specifying dispatchers on a per-tag basis.
I am actually needing a copy of this in our last project. I guess CMF based/CMS related solutions could also enjoy this in order to easily use several event dispatchers and not clutter the Kernel's one.

The new deprecation is simple: Currently, if the pass is called even though the `$dispatcherService` is not available, then it will abort silently. This behaviour is here expanded to any dispatcher specified (If the service doesn't exist, I just let it go). However, starting with Symfony 3.0, I think it would be better to throw an Exception in such cases (This is more consistent behaviour for all errors the RegistrationListenerPass could meet).

Performance consideration: Previously, as soon as the `$dispatcherService` wasn't available, we could abort the RegistrationListenerPass. Now, we still have to process every tag in order to make sure to register listeners and subscribers on others dispatcher. Similarly, if previously a service had several `$subscriberTag` on it, we were doing the processing only once. It is now done for every tag since each one could potentially define a different dispatcher.

BC concern: Now that serveral subscriber tags are processed several times, a Subscriber will be injected as many times as there are tags for a given dispatcher. This might result in duplication of Listeners. However, the risk is already present and ignored for Listeners. If this is deemed as a BWC break, I could easily mitigate it and ensure every dispatcher is processed only once. Once in 3.0, I'd however recommend to either expand this new behaviour to Listeners too, or revert Subscribers subscription to the simple behaviour, just for consistence and least surprise's sake.

BC break proposition: I think since they are now able to register events to any dispatcher, the tags name could be deemed inappropriate. I suggest that starting with 3.0, they renamed to `event_listener` and `event_subscriber`.

BC/Performance tradeoff suggestion: A suggestion to mitigate all these concerns would be to make 2 CompilerPasses available starting with 2.5:

  1. One with the previous behaviour, sticking to `event_dispatcher`, `kernel.event_listener` and `kernel.event_subscriber`), which would be deprecated.
  2. One with the new behaviour using `event_listener` and `event_subscriber`). While deprecating the one with the previous behaviour.

This would coincidentally mitigate the performance concern for the Symfony2 cycle.
*This has not been implemented in the current state of the PR, but I'd be happy to do so if that's the way we choose to go*

In summary, we have to consider the following:

- [ ] Do we check event dispatchers for EventDispatcherInterface implementation?
- [ ] Do we try to mitigate multiple registration of Event Subscribers?
- [ ] Do we plan a rename of the tags starting with 3.0?
- [ ] Do we provide two CompilerPasses starting with 2.5?