Move events into their own crate

## What problem does this solve or what need does it fill?

## What problem does this solve or what need does it fill?

Events in `bevy_ecs` can and should be implemented freely by consumers: many possible variations exist (clearing strategies, parallel but unordered writes, single consumer).

By including them within `bevy_ecs`, we:

1. Risk introducing internal coupling by relying on crate-private APIs.
2. Suggest to end users that they can't and shouldn't write their own alternatives.
3. Clutter `bevy_ecs`, increasing complexity and compile times for both users and maintainers.

## What solution would you like?

Move events into their own `bevy_events` crate.

## What alternative(s) have you considered?

Leave it as is.

## Additional context

#11087 proposes something equivalent for states.