v2.x: Fix RMT mutex unlock using incorrect channel number in rmtDeinit

[paccerdk]

Description of Change

This pull request fixes crashes caused by rmtDeinit function by improving how the RMT channel is handled.

• Added int channel = rmt->channel; at the beginning of rmtDeinit.
• Used channel consistently throughout the function, including for mutex operations.

This change mirrors the approach used in the other RMT hal functions such as rmtLoop, rmtWrite, rmtWriteBlocking and others, ensuring consistency across the codebase.

Previously, the line g_rmt_objects[from].channel = 0; would set rmt->channel to 0 before RMT_MUTEX_UNLOCK(rmt->channel) was called. This caused the mutex to always be unlocked with an incorrect 0 as channel number, leading to crashes for channels > 0.

Tests scenarios

Tested on Lolin32 with Arduino-esp32 core v2.0.16, PlatformIO, VS Code, on Linux.
By calling:

rmt1 = rmtInit(21, RMT_TX_MODE, RMT_MEM_64);
rmt2 = rmtInit(22, RMT_TX_MODE, RMT_MEM_64);
rmtDeinit(rmt1); // no crash (channel 0)
rmtDeinit(rmt2); // crash (channel 1), caused by RMT_MUTEX_UNLOCK(0)

This crashed the ESP32 before the pull request (even with proper error checking), and no longer crashes after the changes of the pull request

Related links

There doesn't seem to be any issues discussing this problem

[CLAassistant]

All committers have signed the CLA.

[P-R-O-C-H-Y]

Nice catch, thank you for the fix.

[me-no-dev]

cc @SuGlider