Added a whitelist for supported models

[sync1211]

This PR adds a whitelist for supported tracker models to prevent unsupported trackers like Standable or Amethyst from cluttering up the UI with unsupported tracker models.

The whitelist currently only contains the model number for the Vive 3.0 Trackers as that's all I have access to.

If you have a different supported tracker, please post a comment with the output of device.model!

[digitalf0x]

Vice-versa, someone recently wanted to trigger the haptics on their controllers despite them not being a generic_tracker, necessitating a custom build to remove that check…

Would it be better to have a list of known-unsupported tracker models to block? That way, if someone tries new hardware, it has a chance of working without modification (instead of the bridge app needing updated for every new hardware model).

(Long-term I want to try to port the UI to a more powerful toolkit, like Qt, so we can have easy scrollbars and resizability. But, y'know, volunteer time…)

[sync1211]

That makes sense, but I feel like it's easier to get a list of supported trackers than unsupported trackers.
For unsupported trackers we could add a checkbox or commandline switch to display them.

I've wanted to get into QT UIs for a while, so maybe I'll take a shot at porting the UI myself.

[digitalf0x]

This PR

Regardless of doing a known-good/known-bad list, a checkbox might make sense. I had previously suggested a "Show only trackers" default-on checkbox for someone who wanted to use their controllers for haptics, needing to bypass the generic tracker check.

In this case, if Zelus prefers to limit to known devices, it might be a "Show only known trackers" instead. That should be saved to the config to avoid needing to toggle it every launch. I'd lean away from relying on a command-line argument since those are a slight pain on Windows.

(EDIT: Tundra Tracker device model seems to be… Tundra Tracker, as per [GUI] Adding tracker: ⚫ LHR-AABBCCDD Tundra Tracker)

Wishlist

With a revamped UI, we'd have a way to hide what you don't use. The checkbox could be "Show only configured trackers" and it'd default to unchecked if no trackers have avatar parameters set, checked if they do (hiding any that don't have a parameter set).

Then, when showing all, instead of completely hiding non-generic tracker devices, the list could be sorted with Configured, Unconfigured-but-known-working, and Untested.

(What I'm not sure about with Qt is whether we'd want to - or need to? - adopt the full Qt application framework, where it provides not just the UI and event loop, but timers in place of background threads, network handling, etc. I've enjoyed contributing to a mid-size Qt C++ client/server app, but I've never touched the Python Qt bindings.)