Fix keyboard-backlight regression on DT-kselftest on MT8195-Tomato

[nfraprado]

There's a regression on a DT kselftest case on MT8195-Tomato (https://lava.collabora.dev/scheduler/job/14714396):

not ok 225 /soc/spi@1100a000/ec@0/keyboard-backlight

But the log shows the keyboard backlight is still there: Starting [0;1;39msystemd-backlight…of leds:chromeos::kbd_backlight....

It is caused by this series: https://lore.kernel.org/all/20240526-cros_ec-kbd-led-framework-v3-0-ee577415a521@weissschuh.net/ , which allowed the keyboard backlight to be discovered through communication with the ChromeOS EC and probed through a separate device instantiated by the MFD framework, hence the device created for the DT node goes unused (and unprobed).

I see a few options:

1. Remove the node from the DT. If I can verify that the platforms using this DT have CrosECs that support the discoverability, then this seems a reasonable option. The DT is supposed to describe devices that can't be discovered otherwise.
2. Add the keyboard backlight driver's compatible to the compatible_ignore_list in the test. The reasoning would be that we can't expect it to be probed through the DT since it might be probed through MFD instead.
3. Extend the dt-extract-compatible script to ignore all compatibles that might be probed through MFD (ie ignore if the driver name appears in a struct mfd_cell). Should check first if there even are enough devices in this situation to justify the added complexity in the script.

[nfraprado]

Sent RFC patch for option1: https://lore.kernel.org/all/20240715-cros-backlight-dt-probe-v1-1-0b5afe64c94b@collabora.com

[nfraprado]

v2 was merged: https://lore.kernel.org/all/172233127627.66997.14875341590066505765.b4-ty@collabora.com/