Support for new event registration subsystem.

Newer devices (SP7, SL3, SB3, ..?) seem to use a different mechanism to enable events.

Copied from https://github.com/linux-surface/linux-surface/issues/201#issuecomment-640298241:

So we'll need to add support for the REG system and enable/disable the events via that. The kbd- commands not doing anything indicate that the old way to enable/disable events isn't being used here.

I've also had a look at the Windows driver, and it seems like the old and new event enable/disable commands have, as far as I can tell (unfortunately I'm not a 100% sure here as the CID/TC values seem to be supplied by the caller and not the registry function), mostly the same code path. So that would indicate that the old and new ways don't play together, but the new is a replacement for the old.

Another thing that I've noticed is the battery. I accidentally added them via IID (instance-ID) 0 and 1, but on the SB2 those were 1 and 2 (this should pretty much have the effect that there are two battery instances created, but they will display the exact same data, i.e. the data of battery 1, which should be the one integrated into the clipboard). I've fixed that now, however, after that I had another look at the battery messages in the logs, and it looks like this is not going to work: It seems like they separated the batteries not by IID but by priority (which I think we should rename at this point, because that use kind of indicates that it's not a priority but maybe rather something like a transfer channel). That is kind of confirmed by one of the REG events: 01 00 02 02 01 (the 02 01 at the end is likely TC=2, i.e. battery/power subsystem and IID=1). So likely, the current branch state will break the battery driver and the old state will show only battery 1, but two times... I'll try to fix that tomorrow.

Just to make sure that they haven't done some controller magic to virtually "merge" the two batteries into one for display purposes: The (extended) battery status on Windows does show two batteries?

So with regards to this, I want to try and find the answers for a couple of questions:
Is the REG system set-up per channel? In the detach/attach IRPMon log, the reg system is only accessed via channel 2, event messages for input devices are sent via channel 2, but event messages for the battery are sent via channel 1 and 2. So to properly enable events, do we have to set up the battery events for channel 1 by accessing the REG system via channel 1?
What are the event messages returned when enabling events for the REG system? Could be currently enabled events or could be events that can be enabled. Part of the payload could indicate if an event has been enabled or not. Or maybe even how many times if it does internal counting. The last two bytes seem to be TC and IID. The byte before those could be the channel. Some example payloads of the event messages:
  01 00 02 03 01

  01 00 02 02 01

  01 00 02 15 01
  01 00 02 15 03
  01 00 02 15 05
  01 00 02 15 06

  01 00 02 21 00
Related to previous: Can events be enabled multiple times (i.e. does it do resource-counting internally or is it just on/off)?

Related to previous: Is there a command to get the currently enabled events (or trigger the event messages sent directly after enabling events for REG)?

When was this introduced? Looks like the SL3 and Pro7 use this too. We might also check SL1/SL2 and Pro6, but I don't think they use that yet.

What about the thermal subsystem (TC=3)? Looks like there is only an event with IID=1 enabled. On the SB2, temperature sensors were separated by IID. Does this still apply or are they separated by channel now? Also those probably require a new driver since they don't seem to accessed by ACPI any more...

linux-surface / surface-aggregator-module

Support for new event registration subsystem. #40