feat(Hardware Support): Razer Tartarus Pro

[dripsnek]

This WIP PR implements support for the Razer Tartarus Pro gaming keypad. To date I've not found anything which allows usage of the analog mode specific to this model under Linux. This aims to resolve that gap.

For the time being it is a tech demo; Basic mode support (barring the scroll wheel #514) is fully implemented but InputPlumber was not needed for that anyway. The analog event handler is implemented but its configuration is hard coded and does not emit to the main event vector, just prints to the log when it would. I think this device is the first of its kind for InputPlumber and how to represent that from a profile perspective in my mind is the major piece of work to go.

This implementation takes full control of the hidraw (x3) and evdev nodes (x4) but passes through the last endpoint allowing lighting control software e.g. OpenRGB to manage the RGB functions whilst InputPlumber is running. The specifics of each endpoint and report type are worth discussing elsewhere.

By default the Tartarus Pro powers up into a basic mode which acts as the left side of a QWERTY keyboard, plus the directional keys and a mouse scroll wheel. Analog mode is opt-in at runtime by sending a specific HID feature report.

The need for a driver exists because analog mode generates vendor defined HID reports that contain the positional value of each key instead of events. These must be processed and mapped to input events and this seemed like a natural fit for InputPlumber to handle.

The analog event handler is implemented using simple linear regressions on a small buffer* to drive a per-key state machine and supports the following:

• User defined actuation points between 1.5mm and 3.6mm depths
• Dual-function keys**
• Retrigger*** with shared or separate upward and downward thresholds
• Wooting-style continuous retrigger***

* The buffer depth of 5 was based on protocol analysis of fast key transitions from the device
** Not intended to operate simultaneously with retrigger
*** AKA Rapid Trigger which seems to be trademarked?

Regarding device profiles, to support analog mode each key mapping would also need to include:

• A couple of u8s to define actuation points for single and dual-function modes
• A couple of f64s to define the retrigger thresholds
• A boolean to indicate continuous retrigger mode is enabled
• Maybe a boolean to indicate use of analog mode as opposed to basic mode if that can't be implied from the above

Out of scope topics:

• There are no plans to include other types of events under this PR considering the recent issues surrounding Snap Tap.
• Hypershift and equivalent has no definition at the driver level. If adopted this would be better done at the composite device level?

Other topics influencing implementation:

• Runtime Switching:
  The Tartarus Pro includes a button and a set of 3 fixed LEDs (separate to RGB registers) to notionally support runtime switching of profiles with the LEDs indicating the active one, hence a 'limit' of 8 profiles. Like most other features on this gamepad it is entirely implemented in software and the button can be remapped like any other. This raises the question of whether InputPlumber intends to support this mode and how this could be agnostically represented in a profile, maybe as a 'flair' type?
• Device details:
  Like a lot of products in this class it is possible to acquire the serial number, firmware revision and other such data from the device registers. This could be used to uniquely assign profiles to a specific device or implement quirks for a given firmware. Should this be incorporated?
• Multi-instance support:
  The Tartarus Pro is a left-handed device but someone, somewhere will somehow find a way to use 2 of them. Should we embrace this or defend against it?

I think these need to happen before removing WIP:

• Decide to keep basic mode or refactor to only manage analog mode
• Decide to keep num_enum crate or refactor impacted code (event.rs / driver.rs - handle_basic)
• If keeping basic mode, feat: add mouse wheel support #514 merged to support scroll wheel remapping
• Incorporate device profile support and remove hard coded settings
• Return device to basic mode either on demand or if InputPlumber closes
• Implement mechanism to dispatch and process feature requests from events (SourceOutputDevice?)
• Write up device usage .md file at nominated location
• Wire up analog event handler to the driver event vector and finalise
• Test what happens when two devices are connected