Safer dynamic event handling for observers

[ItsDoot]

Objective

This is a more scoped version of #14674, with a removal of the "tuple of event types" logic, which is notably controversial. Closes #14649.

Solution

This PR introduces an expansion of trigger-able event data into something slightly more Query-like.
With this, we can safely implement observers that can be triggered with multiple different event types, which don't necessarily need to access the event data. This new type is called DynamicEvent:

// Get our event component IDs somehow. They don't need to be statically known!
let foo_id = world.init_component::<Foo>();
let bar_id = world.init_component::<Bar>();

world.spawn(
    Observer::new(|trigger: Trigger<DynamicEvent> {
        // Called for foo and bar events
        let ptr_mut = trigger.event_mut();
        // If you need to access the event data, you can via the PtrMut returned above.
    })
    .with_event(foo_id) // This method was previously unsafe because it could result in UB.
    .with_event(bar_id) // But we don't do any casting automatically here, so we're safe! (It's on the user's side to do that)
);
// Trigger our runtime-known events dynamically:
unsafe {
    EmitDynamicTrigger::new_with_id(foo_id, Foo(10), ()).apply(&mut world);
    EmitDynamicTrigger::new_with_id(bar_id, Bar(false), ()).apply(&mut world);
}

Testing

• A new test has been added.
• A new benchmark has been added.

Migration Guide

Observer::with_event was renamed to Observer::with_event_unchecked. If you were using this function, consider using a new one that has been added under the old name, which isn't marked unsafe but requires your Trigger<E>'s E type to be DynamicEvent.

[NthTensor]

Very cursory look over, but will do a full review at some point. Approach is very clever, I am very surprised this works and is compatible with propagation. Nice work.

There is still no way to safely access the actual instantiation of a DynamicEvent? Was that in the original? Have we considered returning a Box<dyn Reflect>?

[ItsDoot]

There is still no way to safely access the actual instantiation of a DynamicEvent? Was that in the original? Have we considered returning a Box<dyn Reflect>?

I'm working on adding a separate ReflectEvent type that returns an &mut dyn Reflect. It's not much more code to include it in this PR, if that would help sell it overall.

[NthTensor]

It's not much more code to include it in this PR, if that would help sell it overall.

Cool! Nah, keep it separate imo. This is complete. I will approve as long as it does what it says on the tin.

[SkiFire13]

This safety comment is not entirely clear to me. It doesn't seem to address the safety requirements of the with_event_unchecked function:

# Safety
The type of the `event` [`ComponentId`] _must_ match the actual value
of the event passed into the observer system.

In your safety comment there's no mention of the event ComponentId or the type of the actual event that will be passed into the observer system.

I guess this is safe because DynamicEvent can "match" any event type? If that's the case I would like to see clearer safety requirements from with_event_unchecked that allow for this situation, and a better safety comment here that addresses the requirements from with_event_unchecked.

[alice-i-cecile]

@ItsDoot I quite like this, but it's not vital to get this in for 0.15 so I'm bumping to 0.16. Let me know when you've resolved merge conflicts here though and I'll give you a proper review.