Analyze and improve public APIs for most common peripheral drivers

[jessebraham]

I will likely update this issue with more information once we have discussed our plans a bit more, but in short I think it's time we start doing some top-down design of how we want our public APIs to look for the most common peripherals such as GPIO, I2C, SPI, UART, etc.

We should provide concrete methods for using these peripherals which do not rely on third-party traits. These traits should be implemented in addition to our native APIs, and should be feature gated.

[MabezDev]

I think I've found one area we can look at where we'll get good returns on our effort: timers.

We currently have no shared API between timers, i.e TIMG and SYSTIMER are completely different and cannot be abstracted over, but in reality they both do the same things:

1. Count (clock)
2. One-shot alarm
3. Periodic alarm

If we can abstract over this, I see several benefits:

1. esp-wifi can be decoupled from specific timers, and in general it will be possible to write code that can be abstract over timers. Thanks to runtime interrupt binding, we can even create a InterruptHandler in esp-wifi and assign it to the chosen timer.
2. We might be able remove the embassy time features, though this is still unclear it might need some runtime selection because of how embassy_time_driver::time_driver_impl! works
3. De duplicate code between systimer and timg

We can discuss this in a meeting and begin to hash out a design, I already have some ideas.

On top of that, I noticed that whilst we can initialize Systimer as async, it makes all the alarms async or blocking, in reality there is no technical reason the alarms cannot be mixed and matched as blocking async. There are also Delay impls on the systimer alarms.

[bugadani]

I'm picking up GPIO

[MabezDev]

Closing in favour of #2010