Simplify blocking Delay.

[Dirbaio]

Quick summary of discussions in #177 and in today's REWG meeting:

• We need a hardawre-agnostic, efficient way of representing time durations for use in the e-h traits, but that's probably far away.
• The current DelayMs/DelayUs traits are not the answer, they require duplicating impls for each unit and each integer size.
• There's issues where HALs don't implement all DelayMs/DelayUs combinations, causing some drivers to not work with them.
• However, "blocking delay" is an incredibly important and widely used trait, releasing 1.0 without it is not an option.

The compromise found to unblock 1.0 while mitigating the issues is:

• remove DelayMs
• change DelayUs to use u32 instead of generic width integers.

Why:

• Fixes the pain of HALs not implementing all combinations.
• For the most common use cases (blinks, waiting for chips to initialize...) microsecond precision is enough.
• u32 allows for a max delay of ~1.2h. Such blocking delays should be extremely rare, as the core can do absolutely nothing else during it (unless it uses interrupts, but then you're probably already doing interrupt-based timers).
• The runtime cost of forcing using 32bit is negligible, most HALs are already doing 32bit math on the duration to convert it to clock ticks.

The name Delay is reserved for the future trait that will use the new shiny Duration representation, hence DelayUs is kept even though there's only one trait.

When the final Delay trait is released, we may (or may not if we still think it's handy) deprecate DelayUs.

[rust-highfive]

r? @eldruin

(rust-highfive has picked a reviewer for you, use r? to override)

[Dirbaio]

goddamnit I didn't see #312 🤣