feat: Add ScreenPad device support

[Qonfused]

This pull request adds native support for ASUS ScreenPad devices (e.g. Goodix GDX1515 and BOE BOE087F/BOE085F panels).

Tasks

• Add ScreenPad device initialization for restoring backlight and connector power on boot/login.
  • Read last used backlight + power status from ioregistry.
• Add ScreenPad backlight write/read methods (ref Screenpad Plus Backlight Control ASUS-ZenBook-Duo-14-UX481-Hackintosh#6).
  • Enforce valid writes in accepted backlight range (0x00 to 0xFF).
• Add ScreenPad connector power toggle method.
  • Restore last used backlight value on re-enable.
• Bind hotkeys to screenpad backlight and connector toggle methods.
  • Write current backlight value to ioregistry.
  • Write current connector power to ioregistry.
  • Trigger native OSD backlight notification (resolves Refactor OSD for screenpad backlight #1).

[Qonfused]

What may make the most sense is applying and enforcing the screenpad on with the default backlight value from boot (0x64 or 100/255). Subsequent updates can instead be read from an ioregistry key updated on each backlight/power write.

This lessens the dependence on extracting backlight/power values from potentially variable WMI DSTS/DEVS methods, and instead only uses backlight + connector write methods (which are expected to be consistent).

The use of ioregistry for storing persistent values does need to be further explored.

[Qonfused]

As a compromise, I've added fallbacks to the last stored backlight value in case DSTS methods fail to read the current device state.

[Qonfused]

A concern I had was how to integrate backlight handling w/ SMC keys. Screenpad backlight and power values do not necessarily need to be stored in order for their methods to function, as they are already stored in the EC registers accessible via WMI methods.

Most VirtualSMCAPI keys have some kind of class or method defining types/methods to memoize or otherwise control their internal state. Most commonly, there is an update() method that dispatches a kernel message to AsusSMC (from the daemon). This is all that should be necessary for our purposes since the same methods used for setting backlight + power on boot can be called remotely from the daemon.

This leaves only the SMC key + OSD display coupled with the AsusSMCDaemon and the WMI method handling with AsusSMC.