Followup for adding support for deep and light sleep

[fa993]

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 fmt command to ensure that all changed code is formatted correctly.
• I have used cargo clippy command to ensure that all changed code passes latest Clippy nightly lints.
• My changes were added to the CHANGELOG.md in the proper section.

Pull Request Details 📖

Description

Please provide a clear and concise description of your changes, including the motivation behind these changes. The context is crucial for the reviewers.

Testing

Describe how you tested your changes.

[fa993]

Changes made:

• PinDriver no longer has a generic Pin param
• The type of esp_sleep_enable_uart_wakeup is now an i32 (is this expected)?
• the input type of gpio_wakeup_enable is i32, but all the pin functions return PinId type, which is u8
• Removed RTCWakeupPinTrait and RTCWakeupPin struct, the functionality is directly implemented from - PinDriver. (Since the struct itself was just a wrapper).
• Created a chain function on the RTCWakeupPins trait, so that we can start the chain call with pin_1.chain(pin_2) instead of EmptyRtcWakeupPins::chain(pin_1).chain(pin_2).
• Changed examples which initialise pin driver to initialise it with state of Pull::Down

Changes not done:

• Completely Removing RTCWakeupPins trait for unsupported cfg directives (bigger change, will do it after initial changes are cleared off).
• GPIO subsystem modifications, once RTC approach is cleared off, will apply the same to it.

Changes that I would like to do:

• Completely eliminate the EmptyRtcWakeupPins struct.

[ivmarkov]

If you want the CI to succeed, you might want to put

#![allow(unknown_lints)]
#![allow(unexpected_cfgs)]

at the top of your example.

And then look at the remaining Clippy errors.

But it would be good to fix the CI before requesting a review. I'll be able to review mid/late next week (on travel ATM).

[fa993]

Yeah.. no I was wondering why the CI was failing myself, (the feature flags used weren't anything new and not present in the codebase), I'll fix the remaining errors and make sure CI is passing before the next review.