Queue and collate fan requests (and output_pin and servo)

[KevinOConnor]

This PR adds a new mechanism for queuing of fan updates. (It also applies to output_pin and servo objects.) Due to the low-level mechanism used to transmit updates to the mcus, it is necessary for each update to apply for a minimum amount of time - typically 100ms. Previously, if one were to send many fan updates in rapid succession, the code would batch up those updates and apply them in succession. (With each update running for at least 100ms.) This could result in the fan updates becoming out of sync with the toolhead.

This PR adds new code to collect fan updates in the host and only send the latest fan update to the mcu. For example, in the following sequence:

G4 P2000
M106 S100
M106 S101
M106 S102
M106 S103
M106 S104
G1 X100

The old code would apply four fan speed changes spaced over 500ms. The new code will send just a single update (M106 S104).

This change should make Klipper a little more resilient with buggy slicers. It is also part of a series of changes I have been working on to add support for asynchronous pin changes.

-Kevin

[github-actions[bot]]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.