Add trait for count down times that allow reading out elapsed time

[nickray]

Concrete suggestion to resolve #186.

I'd prefer Elapsed::elapsed to be infallible, but that is probably against the tide of the times :)

We use pretty much this implementation in https://github.com/lpc55/lpc55-hal/blob/5c70be5f73da2a6e1330aefc82a53f6cd3ddc7d6/src/drivers/timer.rs#L43-L48; looking at various STM32 and the nRF HAL this seems very implementable.

Of course this is infinitely bike-sheddable (remaining? now? etc...), it would be a pity not to have a standardized way of reading out a timer if embedded HAL is headed for a 1.0.

Perhaps Elapsed would pair better with a CountUp timer, and Remaining with a CountDown timer?

The trait is "add on" on purpose, the goal being to have a simple upstream trait to bound on (perhaps bounding Self::Time on some embedded-time type) in drivers and portable firmware. The Timer type (!) from embeded-time seems too heavy-weight with its generic parameters, and rtic-monotonic has additional requirements.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ryankurte (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[eldruin]

Looks good to me. I can imagine elapsed() implementations returning an error if the timer was canceled in the mean time, for example.
Maybe some more documentation about this could be added.