Upstreaming some concepts built up in `embedded-time`

[Ben-PH]

Just now, I forked embedded-hal with the intention of upstreaming some constructs that I've been using in embedded-time. This issue is to put this out there for visibility. If others are working on it, or if I've missed work that makes my fork redundant, this issue should reduce the risk of unfortunate double work.

Some relevant issues

211

359

Why I'm doing this

I'm very happy with embedded-time, though it seems to be stale/abandoned (last commit to main: 3 years, little other activity). There are some little (perhaps opinionated?) changes I'd like to see that I'll be making as I upstream into my fork, which I hope to eventually upstream to embedded hal

How upstream?

I will be following the contribution guidelines. I anticipate the initial PR (if all goes well), to put things behind a feature gate so as to be as unintrusive as possible, and as a rule, defer to the WG recommendations.

[Ben-PH]

Notes:

• Nothing is to be forced onto reverse dependencies. if the implementor is reading from a u32 register, they would most likely implement it such that it outputs u32. Likewise for u64/16/128/etc.
• I will personally downstream the use of any tick-count oriented stuff in embedded-hal into crates where it makes sense, including embassy-time, esp-rs, and any projects where it makes sense to do so.
• of note: in the esp-rs chat rooms, a skeptical comment was made about using embedded-time due to it being stale/abandoned.
• I want to avoid any checken-egg problem. I don't want there to be a gaping-hole where a canonical representation of tick-counting should be because there isn't something that's popular, and people aren't using a canonical representation because there isn't a coordinated effort to make one.