Add RGB lighting persistence via SW control claim for G515/G502

[ksanislo]

When Solaar claims LED control, properly disable firmware power management via ProfileManagement or OnboardProfiles and claim the LED pipeline with SetSWControl(mode=3, flags=5). This prevents the device from reverting colors to its onboard profile after a few seconds.

Adds cleanup handler to restore firmware control on device close, and auto-claims SW control when writing per-key lighting colors. Adds PROFILE_MANAGEMENT (0x8101) feature constant.

This is manually extracted, line for line from the larger patch set. It demonstrates just the absolute minimum base functionality to make the keyboard hold set colors. It's not tested beyond firing it up and giving it quick "yup, that works" when it didn't lose the keyboard colors after 10 minutes, then switching back to a proper implementation.

I highly recommend not using this branch for anything beyond basic testing. Without software based power control, this will be quite hard on the battery, and I'm suspicious that it may reduce the overall lifetime of the hardware in general. Being regularly "stuck" in full power mode for extended periods probably wasn't a design consideration, as it should be a relatively rare event under normal circumstances.

[pfps]

The feature for RGB lighting has methods for controlling power, so it looks to me that using them will be better than having Solaar monitor device activity.

The issue is how to prevent onboard profiles from interfering with power management. Maybe it is sufficient to just have Solaar set up power management. (But for some features, onboard profiles prevents any change via the dedicated feature.)

[ksanislo]

By all means, if you can find a way to get this keyboard to play nice without using software control, you're plenty welcome to give it a shot yourself. I personally couldn't find a way to keep the firmware from overwriting the active lighting with its own internal behavior without either writing a saved profile (not great for interactivity) or using software control, and once you go into sw control you have to manage reading events and switching power modes in response yourself. If you check the latest update to the complete implementation, you can see how it's intended to work under software control and switching the sw control flags based on activity.

[ksanislo]

Closing this PR since I don't believe it should go in without the rest of the implementation. I'll keep my branch for this in place however, if you wish to look at it further.

[pfps]

I'm going to mark it as a draft instead. That should be enough to show that it shouldn't be merged and prevent it from sinking into obscurity quite yet.