CONTRIBUTING.md: how to report a device, record a USB capture and open a pull request

[ahmedkhursheed23]

This PR adds CONTRIBUTING.md, a short guide for people who want a device supported or want to add one. The README links to it from Troubleshooting.

Base and other PRs

• Base: main at e80dfd1.
• Files: CONTRIBUTING.md (new), docs/contributing/diagnostics-menu-dark.png and -light.png (new, 38 KB and 43 KB), README.md (one sentence in Troubleshooting step 3).
• README is getting long: a shorter support table and a docs/protocols.md for the per-device detail #90: this PR does not change the supported devices table. Moving the table is the subject of README is getting long: a shorter support table and a docs/protocols.md for the per-device detail #90 (@casparas123), so this PR does not do it again. The two changes do not overlap: README is getting long: a shorter support table and a docs/protocols.md for the per-device detail #90 can link to CONTRIBUTING.md from the new, shorter README.
• Conflicts (trial merges): none with Razer BlackShark V2 Pro (2020): read its battery over the receiver's 64-byte feature report #111. Tray: device type switches (#96), per-device alert level, time left, percentage icon, quiet while gaming (#76), status file; Audeze stuck dongle and 0% at power-on, unit tests #107 already conflicts with main in five files (in README.md, the Preferences list); the sentence that this PR adds is in Troubleshooting and does not add a conflict.

Why

Many device requests arrive without diagnostics, with a part of the diagnostics only, or with a USB capture that does not contain the maker's app traffic (#74 needed two retakes). The same instructions are written again in each issue. GitHub shows a link to CONTRIBUTING.md when a person opens an issue or a pull request, so the instructions are in one place.

What the guide contains

1. Report a device: close the maker's software, wake the device, attach the complete diagnostics file, write the level that the maker's app shows. Serial numbers and MAC addresses can be removed.
   • A screenshot of the tray menu with Diagnostics… marked. It is the real Fluent menu of main, in the dark and the light theme; a <picture> element shows the one that agrees with the reader's GitHub theme.
   • A short sample of the report (real output of --probe, with the unit id removed), and where the file is (%APPDATA%\HaloBattery\diagnostics.txt).
2. Record a USB capture: links to USBPcap's illustrated guide (screenshots of each Wireshark window) and the Wireshark USB page. Then why the app sends only known commands, then the Wireshark and USBPcap steps in the order that works (close the maker's app, start the capture, start the app). If the capture has no app traffic, change a setting (for example the DPI) to test that the capture sees the app. A note that Bluetooth levels come from Windows.
3. Open a pull request: branch from main, use the provider of the protocol family, register a new provider, name the source of every command, add tests with fake HID devices, update CHANGELOG.md and the table, and write the source, the hardware test and the related PRs in the description.

The guide uses short sentences and numbered steps, so that people who do not speak English as a first language can follow it.

Test

• All relative links were checked: ../../issues/new goes to the issue form, the same pattern that the README uses for ../../releases/latest.
• The menu names in the guide (Diagnostics…, the "No devices found" icon) and probe.bat agree with halo_battery.pyw on main.