[Driver] 3-color e-Ink on Quantum Painter

[elpekenin]

Description

Just a convenience wrapper around 2x 1bpp surfaces, since there are some yellow (and perhaps other colors) ones, the driver holds the HSV target color, so that palette_convert can map any input color to the closest of the three.

About similar hardware:

• This driver aims displays which can't be partially updated and force us to store the framebuffer
• BW displays could be made similar to OLEDs (using a single 1bpp surface)
• Partial update-capable ones could probably work with code similar to TFT panels (viewport + stream data)

So far tested with IL91874 #19437
Another Discord user is testing SSD1680 #19451 -- However, im unsure if this display could reduce its RAM usage and/or get better performance with a partial update driver, since it supports such feature.
⬆️ Both those PRs need updates. The docs + painter/rules.mk changes will be contained on them

Since these displays can get damaged if drawn too often, code uses a flag to control whether we can do it:

• Set to false upon flushing + defer_exec to schedule getting it back to true
• This flag is false at startup, preventing double-flushing if the keyboard is rebooted and it performs drawing at init (or soon enough) -- will happen as soon as Quantum Painter QoL enhancements -- auto-poweroff, auto-flush, buffer sizing #20013 lands

---

⚠️ The code to store data in the global buffer is a bit messy, but optimizes RAM usage by storing 4 pixels per byte (ie: all space available) -- It might break if the size of the buffer is not an even number of bytes, *but* code doesnt make any check about this since there is a check on QP internals that ensures it is a multiple of 16

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[elpekenin]

Draft as it needs surface to be merged first

[elpekenin]

Maybe the function shouldn't have this early stopping and just keep running anyway, and let return ret; give the false value 🤔