Provide access to the original target of entity-events in observers

[alice-i-cecile]

Objective

Getting access to the original target of an entity-event is really helpful when working with bubbled / propagated events.

bevy_picking special-cases this, but users have requested this for all sorts of bubbled events.

The existing naming convention was also very confusing. Fixes #17112, but also see #18982.

Solution

1. Rename ObserverTrigger::target -> current_target.
2. Store original_target: Option<Entity> in ObserverTrigger.
3. Wire it up so this field gets set correctly.
4. Remove the target field on the Pointer events from bevy_picking.

Closes #18710, which attempted the same thing. Thanks @emfax!

Testing

I've modified an existing test to check that the entities returned during event bubbling / propagation are correct.

Notes to reviewers

It's a little weird / sad that you can no longer access this infromation via the buffered events for Pointer. That said, you already couldn't access any bubbled target. We should probably remove the BufferedEvent form of Pointer to reduce confusion and overhead, but I didn't want to do so here.

Observer events can be trivially converted into buffered events (write an observer with an EventWriter), and I suspect that that is the better migration if you want the controllable timing or performance characteristics of buffered events for your specific use case.

Future work

It would be nice to not store this data at all (and not expose any methods) if propagation was disabled. That involves more trait shuffling, and I don't think we should do it here for reviewability.

[viridia]

Naming: I suggested the named "listener" (to refer to the current target) and "emitter" (to refer to the original target). Note that "listener" used this way is consistent with the original bevy_eventlistener, while the term "emitter" is my own.

[alice-i-cecile]

Naming: I suggested the named "listener" (to refer to the current target) and "emitter" (to refer to the original target). Note that "listener" used this way is consistent with the original bevy_eventlistener, while the term "emitter" is my own.

Not unreasonable, but I would really like to avoid doing that in this PR. I've opted for the least controversial names to avoid blocking this work on bikeshedding. #19263 is the place to discuss names.

[Jondolf]

Slightly different from web conventions (target is the current target instead of the original one), but very reasonable. Happy to have the originally targeted entity available for more than just picking!

[Jondolf]

Nit: Is there a reason to call this current_target even though On has target? I suppose it is clearer, just mildly inconsistent

[alice-i-cecile]

Yeah, I decided for clarity over consistency here, but I can swap it.

[alice-i-cecile]

@emfax can I get your review here? :)

[emfax]

I think it wise to remove target from Pointer.

current_target and original_target were actually my preferred names, but I didn't want to be too controversial and just introduced current_target.

Looks good to me.

[rendaoer]

This is really great. I always struggle with whether to use pointer target or trigger target()