feat: event dispatcher before after

[nikophil]

Q	A
Branch?	6.4
Bug fix?	no
New feature?	yes
Deprecations?	no
License	MIT
Doc PR	will be done if feature gets accepted

When hooking into the event system, it's a common need to define the priority compared to another existing listener:

// should occur BEFORE "router_listener"
#[AsEventListener(event: KernelEvents::REQUEST, priority: 33)]

// OR

// should occur AFTER "router_listener"
#[AsEventListener(event: KernelEvents::REQUEST, priority: 31)]

This is not optimal: without the comment it is not clear why the listener has the given priority, and this is not enforced by code.

I'd like to propose another approach, and introduce a new way to handle priorities between listeners:

// the listener will occur before "router_listener::onKernelRequest()"
#[AsEventListener(event: KernelEvents::REQUEST, before: 'router_listener::onKernelRequest()')] 

 // the listener will occur after "router_listener::onKernelRequest()"
#[AsEventListener(event: KernelEvents::REQUEST, after: 'router_listener::onKernelRequest()')]

before and after priority should follow these rules:

• it must satisfy the pattern {serviceId}::{method}()`
• trailing parenthesis could be omitted
• if the listener is invokable, only the serviceId can be provided

The idea here is to rely on the priority system and to guess the priority of the listener based on its "before" or "after" attributes (the priority computation would be recursive if the given before/after listener should also occur before/after another one).
In the proposed implementation, the priorities for all listeners using before/after are computed in RegisterListenersPass before we loop over the listeners.

Here are some rules:

• if a listener uses before/after, it must listen the same event than the listener which is referenced
• a listener cannot have a priority configured and use before/after
• a listener cannot declare at the same time "before" and "after"
• we should detect circular references

Here is a first draft PR of the implementation, it's missing a lot of stuff:

• tests
• ability to define before/after in php, xml, yaml
• doing the same thing with subscribers
• certainly some edge cases are not handled correctly here

at this point, I'd like to have early feedback about the idea and if it has some chances to be accepted. and if the given implementation is the way to go?

I think if this feature is accepted, it would be nice to commit this feature to all tags using priorities, and then add it to PriorityTaggedServiceTrait

thanks for your feedbacks!