Buzzer based on HW Event

[digant73]

As discussed with @rondlh, just posting here his reviewed PR #2852 to possibly speedup its merge. I used his buzzer implementation based on HW event since a lot of time with no issue at all. All credits to @rondlh.
IMHO, with this PR all the more important/useful features have been provided in the TFT and probably it will require from my side just a minor support for maintenance/real bug fixes if any will be reported by users.
This PR also includes a bug fix introduced by last merged PR #2889 causing an infinite sending loop for a gcode purged by the TFT.

Below just the description of this PR as provided by rondlh in his PR #2852.

IMPROVEMENTS:
This pull request consists out of 4 parts, here they are in order of importance:

1. Print hesitation bugfix. The current TFT sound playback system has a queue of 5 slots that stores the sounds to be played before playback starts. The problem with the current implementation is that if the queue is full, the sound system will block all processes until a sound queue slot becomes available. During this time even printing will be paused because the system is just waiting for a sound slot to become available. This behavior can cause hesitations in the printing process. This PR solves this issue by prioritizing the printing process over sound playback system so no print hesitation can occur because of sound playback.

2. Event driven sounds, no polling. Currently sounds are stored in the sound queue by gcode commands or if the system wants to playback a notification/error/warning sound. These events don't actually start the playback of the sounds. This happens in the main processLoop, where a check is done to see if there are sounds ready for playback in the queue. This process is called polling. This PR makes this process event driven, which means that the arrival of a sound for playback immediately start the sound playback, and the playback of any sounds that arrived afterwards. No check is required in the main loopProcess anymore. This will result in a small efficiency/speed improvement, and can serve as a example of how to efficiently implement event driven processes. Polling should be avoided when possible.

3. Host sounds. Most printer motherboards do not have a speaker/buzzer, one can be added of course, buy why not use the buzzer of the TFT? This process is supported by the Marlin ExtUI interface and works by forwarding the sound that should be played by the motherboard to the TFT. The TFT then takes care of the playback. This PR adds this capability.

4. Remote sound mute/unmute. Additional functionality is added to give the user remote sound control by allowing sounds to be enabled and disabled via the M300 commands. A ESP3D can be used to mute or unmute sounds remotely without using the touch screen.

Benefits

1. Preventing possible printing hesitations causes by the sound playback when the sound queue is full.
2. Improving the TFT efficiency by not needing to poll the buzzer queue anymore, and showing how event triggering can be used to prevent polling.
3. TFT is capable of playing back sounds for the motherboard.
4. Remote mute/unmute sound control (via Wifi)

Note

This PR affects hardware dependent code (interrupts), which requires testing to make sure the code works on all supported hardware platforms. Actually the changes made are quite small, sounds were already using interrupts. The main difference is that when a sound playback is completed, the process doesn't just exit to let the loopProcess restart it, instead the process check if more sounds need to be played and starts this task immediately, so no attention from loopProcess is needed. This code has been tested on STM32F1xx, STM32F2xx, STM32F4xx and GD32F2xx.

BUG FIXES:

• fixed a bug introduced by Added Command Checksum + code optimization + cleanup #2889 causing an infinite sending loop for a gcode purged by the TFT

resolves #2845