Update our time driver for upcoming embassy changes

[bugadani]

Update esp-hal-embassy for the new embassy-time-driver version.

We now manage our own timer queues, which means that

• if there are multiple queues (with integrated-timers), we can use a priority-limited mutex. This means that higher priority executors don't get blocked by lower priority ones (except for Priority1 which may be blocked by the thread mode executor, but that's it).
• if there is only a single queue (integrated or generic), we use a max priority lock (same thing as above, but instead of a critical section we end up with a spin lock).
• the embassy-side changes mean processing the timer queue has a much lower overhead when using integrated timers.

Configuration-wise, users have the options to select between:

• N integrated queues (requires N alarms)
• 1 integrated queue
• generic timer queue (for RTIC, for example) - this is the default if integrated-timers is not set, but probably should be inverted at this point, or at least default to single-queue.
• The size of the generic queue is configurable using ESP_HAL_EMBASSY_GENERIC_QUEUE_SIZE

---

I'm removing the trouble-host example with this PR because

• They are also present in the trouble repo https://github.com/embassy-rs/trouble/tree/main/examples/esp32
• The above example means these two repos had circular dependencies on each other, making breaking changes (like the current PR) impossible to manage

---

What's needed:

• async-io-mini release
• Update embassy-time ivmarkov/edge-net#54
• edge-net release

[bugadani]

We need to figure out passing config options to tests for this. We should also figure out testing multiple feature sets, or configs in this case - otherwise we won't be exhaustive in our async tests. Although only the integrated timer is our implementation, it would be interesting to test the time driver's ability to provide multiple alarms, too.

[jamessizeland]

I'm rooting for you! 💪