keyboard: Udev configuration for "wakeup keys"

Closes: #363

https://github.com/systemd/systemd/pull/32261

Example configuration for my Samsung A5:

ENV{ID_PATH}=="platform-i2c-tkey", ENV{PHOC_WAKEUP_KEY_DEFAULT}="0"
ENV{ID_PATH}=="platform-200f000.spmi-platform-200f000.spmi:pmic@0:pon@800:resin", ENV{PHOC_WAKEUP_KEY_114}="0"
ENV{ID_PATH}=="platform-200f000.spmi-platform-200f000.spmi:pmic@0:pon@800:resin", ENV{PHOC_WAKEUP_KEY_potato}="0"
ENV{ID_PATH}=="platform-200f000.spmi-platform-200f000.spmi:pmic@0:pon@800:resin", ENV{PHOC_WAKEUP_KEY_115}="potato"

This configuration will log the following warnings:

(phoc:20094): phoc-keyboard-WARNING **: 19:20:33.208: udev property 'PHOC_WAKEUP_KEY_115' has invalid value 'potato': should be '0' or '1'
(phoc:20094): phoc-keyboard-WARNING **: 19:20:33.208: udev property 'PHOC_WAKEUP_KEY_potato' has invalid keycode 'potato': should be a positive non-zero int

All keys from the platform-i2c-tkey input device will be ignored when the device's internal display is disabled. The keycode 114 from the :resin input device will be ignored but other keys from that device will wake the display.

Original MR description

@guidog I know you said this could/should go upstream but I'm curious what you think about this initial stab. That is, just doing the needful udev walking when constructing a PhocKeyboard like I've done here. I figure that if this approach works, we could merge something like this (pending cleanups and desired changes), and then see about trying to push it further upstream?

Also I actually started by trying to figure out how to just do a hardcoded config thing. But since you said phoc.ini wouldn't be mergeable and gsettings would be better, I spent a solid hour or two trying to wrap my head around how to do a gsettings thing with arrays of ints. I've got some staged changes with the schema and such, but I'm a bit out of my depth with GLib ;)

When I realized how simple it would be to just grab the config out of udev like you see here, I jumped on that because I think it's the most ideal approach anyway. With this approach the ignored keycodes are specified on the specific device which is something you mentioned would be desirable. I understand that now this is hard to test since a nested compositor doesn't get the raw libinput devices, so if/when you're happy with this initial stab I'd love some mentoring on how to deal with the "let's do an OOP thing in C" that is GLib ;)

Example udev rule I tested on my samsung-a5 to prevent the bottom capacitive buttons triggering screen wake:

ENV{ID_PATH}=="platform-i2c-tkey", ENV{PHOC_IDLE_IGNORE_KEYS}="158,580"