Provide a way to base Timer on some Time object

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

The docs for Bevy 0.13 indicate `Time` provides a timer running at a multiple of the system clock. `Res>` can be sped up, slowed down, or paused to control game time, so long as the game's objects are tied to `Res>` for their time.
The docs don't indicate a way to produce a `Time` based on `Res>` or another `Time`.

Further, the docs for `Timer` don't indicate whether `Timer` follows `Res>` or `Res>`, and there is nothing in the docs indicating any way to control this.

For events with cooldown, it would make sense to be able to somehow time the cooldown relative to a virtual timer tied to game time. For example, Final Fantasy's active time battle system uses a character's speed to slowly fill a time gauge before the character's turn begins; while several games have cooldown times for using special moves. These times can be made faster or slower by status effects to increase or decrease a character's speed. A good approach to do so is not obvious.

There are also speedup and slowdown mechanics such as dialog box speed or battle speed in RPGs separate from the rest of game time. These somehow require timing against a clock relative to the main game clock.

## What solution would you like?

A way to time events based on a given time source. One approach is to allow creation of a `Time` based on some other `Time` object specified by the programmer, and adjust the `Time` speed to compound with its base clock. For example, `my_time` can be set to 0.5 speed and based on `Res>`; setting `Res>` to 0.5 speed would have `my_time` run at 0.25 system speed.

A way to create a timer based on a `Time` object to go with this. `my_timer` could then be a `Timer` based on `my_time`, and speeding up or slowing down `my_time` would affect the length of real-time required for `my_timer` to finish.

## What alternative(s) have you considered?

Writing a custom timer by simply reading `Res>` and looking at the current virtual time versus a recorded virtual time at which the timer started. This offloads the entire function of `Timer` onto a custom implementation, which means every programmer needs to implement their own type of `Timer`.

No files or tests are named. Begin by reviewing the documented Time, Time, and Timer behavior, then trace how time sources are currently selected. Done should include a clearly defined API for derived time sources and timers, with coverage for compounded speed changes and cooldowns.

Written by the indexing model from the issue text.