Implement Delay from embedded-hal 1.0

[holly-hacker]

Closes #192

This PR implements Delay from embedded-hal v1.0 for stm32f0xx_hal::delay::Delay and uses a u64 tick counter instead of a u32 tick counter to increase the range of time the user can sleep.

Since stm32F0xx-hal's prelude imports the entirety of embedded-hal v0.2.7's prelude, importing embedded-hal v1.0's DelayNs trait may cause some ugly resolution conflicts on the delay_us and delay_ms functions but this is not something users should be doing often and the timer isn't accurate enough for delay_ns to be useful anyway.

u64 tick counter overhead

From my testing, using a 64-bit counter did not increase the overhead of the timer for low values (delaying 1ns still takes ~700ns) even though the Cortex-M0 does not have 64bit arithmetic. I assume this is due to compiler optimization and inlining. If I force this optimization to not happen by passing the input through core::hint::black_box, I get the following cycle counts (all on opt-level='s', lto="fat", STM32F070RB @ 48MHz, measured using SYST::get_current() at call site):

	u32 (optimized)	u64 (optimized)	u32 (black_box)	u64 (black_box)
1 ns	33 (687.5 ns)	33 (687.5 ns)	45 (937.5 ns)	116 (2.42 us)
1 us	110 (2.29 us)	110 (2.29 us)	107 (2.22 us)	189 (3.93 us)
5 us	294 (6.12 us)	369 (7.69 us)	298 (6.21 us)	375 (7.81 us)
10 us	536 (11.17 us)	611 (12.73 us)	538 (11.2us)	617 (12.85 us)
100 us	4859 (101.22 us)	4934 (102.79 us)	4859 (101.23 us)	4940 (102.92 us)

I briefly experimented with having delay_ticks_u32 and delay_ticks_u64 based on the requested tick count (by comparing us or ns to 0xFFFF_FFFF/48), but I don't think the code duplication was worth the trade-off since people that need sub-1us timing will likely implement their own delay loops.

[holly-hacker]

Force-pushed to solve changelog merge conflict