Add embassy executor cpu stats

[Szybet]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Added CPU usage measurements via Embassy executor using the low_power_wait feature

Description

Based on this PR: embassy-rs/embassy#3920, added the same functionality internally (not as an example). Also added it to the new YAML-based config, but couldn't find a way for the config to check if the required low_power_wait feature is enabled, as none of the existing validators (negative_integer, non_negative_integer, positive_integer, integer_in_range, enumeration) are suitable for this.

Testing

Used it to debug an issue with bad UART communication, because CPU was fully being utilised by another part of the program.

[bugadani]

Suggested change

	esp-hal = { version = "1.0.0-beta.1", path = "../esp-hal", features = ["unstable"] }
	esp-hal = { version = "1.0.0-beta.1", path = "../esp-hal" }

We intentionally don't enable the feature.

[Szybet]

Without it it doesn't compile standalone. If that is intentional I will disable it

[bugadani]

You need to enable unstable in your own project, not like this.

[Szybet]

done

[Szybet]

As #3737 is merged do you wish to redo this PR as an example using hooking into executor? I would still be beneficial to have something like that visable for new devs

[bugadani]

Sure, why not? rtos-trace is a bit better tool to gather usage stats in general, but this would still be a fine example.

A few notes:

• Use esp_hal::time::Instant so that the stats aren't dependent on the time driver's tick rate
• Make sure you collect stats into different counters for different executors.
• We should ideally extend this to interrupt executors, too. You don't have to, but if you have a good idea, you can play with it as a stretch goal. Most likely the callbacks should be part of the constructor & the type of the executor. This also means that the timings you measure can overlap (thread executor starts polling, interrupt happens & interrupt executor start polling, interrupt executor finishes, thread executor finishes). We probably don't want to end up measuring >100% CPU use.

[Szybet]

I would like to write the example with #3813 as it's simple, perfect for an example, so I will wait for it to be merged (in one form or another)

Make sure you collect stats into different counters for different executors.

Is that a thing you can do now with #3737?