Detect `EventReader`s consuming double buffered `Event`s.

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

Ordering systems with `EventReader`s and `EventWriter`s is important when you want to ensure the `Event` chains take place in a single frame.
In an application that runs at a low interval fixed time schedule it is undesirable to have event chains take several milliseconds worth of processing, because systems are lazily ordered.

This feature would be especially handy for `Bevy v0.12+`, because by then `FixedUpdate` schedule will support `EventReader`s.
This way you can enjoy the safety of double-buffered events and not run into unexpected event misses (which is so important for dev iteration speed and preventing the otherwise required debugging sessions) while still also being warned about systems that might still be lazily ordered and could do better.

## What solution would you like?

Passing configurations via `App` that allows you to optionally enable detecting double buffered events and log them. For example how the ambiguity detection works with [ScheduleBuildSettings](https://docs.rs/bevy/latest/bevy/ecs/schedule/struct.ScheduleBuildSettings.html#).
Optionally include the ability to enable or disable this detection feature per `Schedule`. For example in `Update` it could be acceptable to have double-buffered events since it runs as fast as it can, whereas in `FixedUpdate` the frame delays are a bigger problem.

## What alternative(s) have you considered?

Creating `Event` struct `EventWrapper` where T is a unique `Event`. Only add, read and write events that are wrapped like `EventWrapper`. `EventWrapper` has a custom event id field. Every single system would need to get updated code to generate custom ids, store them in a `Resource` on send and to retrieve to compare them on read.
This is a lot of work. There is no ideal way to currently do this to my knowing.

## Additional context

My project has several lazily ordered systems that I would like to track down and fix. The project currently has 100+ unique `Event`s with more systems that read and write to them.