Add a standardized way to track simulation time for interoperability

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

There is currently no universal way to track the time of a running simulation. If it's just needed in user code it's simple enough to create a resource that tracks the number of ticks since the simulation started and use some constant for timesteps. However, when third-party plugins get involved there is no good interoperable solution. Some crates provide their own type, resulting in some vendor lock-in. Other crates can be configured for where to source their time, making them harder to set up.

These types are further complicated by conflicting needs of different crates. A networking crate most likely has a counter it only needs to go up, but a rollback crate depending on that networking crate would need it to also go backwards.

## What solution would you like?

A centralized way to track the time in a simulation. It could be a fairly simple type like:

```rust
type SimulationClock {
tick: u64,
timestep: Duration,
}
```

It could either be it's own thing or a variant for `Time`, as `Time`. Incrementing it could either be left up to the user, or configured in a more out-of-the-box way like deciding between FixedUpdate and the main loop depending on the app's runner.

The tick value could also be a newtype on `u64` (or `u32`) so it's clear what these values mean if they are requested in function signatures or stored in other types (for example storing the tick on which an event happened).

## What alternative(s) have you considered?

- Add the counter to an existing resource, like `Time`, but this wouldn't be ideal for apps that run at a fixed rate without FixedUpdate.
- Don't add an official way to do this and keep the fragmented approach without interoperability.
- Create a third-party plugin that provides a type like this, and convince everyone to use it

## Additional context

Here's a few crates that deal with some sort of simulation tick:

[ggrs](https://docs.rs/ggrs/latest/ggrs/type.Frame.html)
[bevy_replicon](https://docs.rs/bevy_replicon/latest/bevy_replicon/core/replicon_tick/struct.RepliconTick.html)
[lightyear](https://docs.rs/lightyear/latest/lightyear/shared/tick_manager/index.html)
[bevy_bundlication](https://docs.rs/bevy_bundlication/0.3.0/bevy_bundlication/prelude/struct.Tick.html) (disclaimer: I wrote this crate, the next version will likely also no longer have this type since it has been rewritten as a layer on top of bevy_replcion)

Start by reviewing Bevy's existing Time, FixedUpdate, and app runner concepts, then compare the simulation-tick needs described for ggrs, bevy_replicon, lightyear, and bevy_bundlication. The work is done when a settled, interoperable clock design and its ownership, tick direction, timestep, and integration point are agreed.

Written by the indexing model from the issue text.