Add trivial Event trait

[alice-i-cecile]

Objective

• The trait bounds on e.g. EventWriter<T> are currently confusing to users: why does it matter if the underlying type is a resource?
• This is actually misleading: the type T is never stored as a resource, instead, Events<T> is inserted as a resource.
• However, because of the blanket implementation of Resource, any Events<T> will be Send + Sync + 'static if and only if T is.
• Down the line, if we want to make either Event or Resource non-trivial, this coupling will be confusing and error-prone.

Solution

• Add a trivial Event: Send + Sync + 'static trait, and use this in place of Resource in the assorted event types.
• Create a blanket impl for Event so users do not need to manually implement or derive this trait (yet).

Changelog

• Events<T>, EventWriter<T>, EventReader<T> and so on now require that the underlying type is Event, rather than Resource. Both of these are trivial supertraits of Send + Sync + 'static with universal blanket implementations: this change is currently purely cosmetic.

Context

This was first discussed in the context of the more controversial #2073.

You can see the confusion that this sort of conflation generates in #4680 (comment), where the changes made to the Resource trait echo through to our event types in surprising ways.

Down the line, there's an argument to be made for forcing a derive macro on both Resource and Event, and supporting more configuration, but that's a conversation for another day.

[mockersf]

I updated #3863 (which as far as I know shouldn't have anything controversial) with the doc and type renamed from this PR. If you prefer to go with this one, you should also change in bevy_app:

bevy/crates/bevy_app/src/app.rs

Lines 623 to 625 in 743bd30

	pub fn add_event<T>(&mut self) -> &mut Self
	where
	T: Resource,

[alice-i-cecile]

Closing in favor of #3863.