serial_hid: add support for the WCH CH9329 chip (UT-D09 cables, newer…

[nitrotm]

Chip identity and protocol were confirmed by looking into the vendor
driver (UNI-T's CH9329DLL.dll, shipped alongside its CP2110 driver in
the UT181A Windows install) and cross-checking against the public
CH9329 datasheet and serial-communication-protocol document:

• The HID report descriptor is purely vendor-defined, declares no
  report IDs, and uses three FIXED 64-byte reports (Input/Output/
  Feature) -- unlike WCH CH9325 (see serial_hid_ch9325.c), which uses
  8-byte reports and a real per-session baud rate Feature report.
• Input reports need no report-ID placeholder byte: byte 0 of the
  64-byte report is a plain (unmasked) count of valid UART RX bytes
  that follow, 0..63. This matches the chip's CMD_READ_MY_HID_DATA
  data-plane command (0x87), which auto-packages 0..64 UART bytes
  into the HID Input report.
• Output reports, since this device declares no report IDs, still
  need the hidapi-mandated placeholder byte ahead of the report
  content (hid_write() expects the report ID, 0x00 here, as the
  first byte, with the call length equal to report size plus one).
  The actual 64-byte report content is then, symmetric to Input, a
  plain (unmasked) count of valid UART TX bytes followed by the data,
  matching CMD_SEND_MY_HID_DATA (0x06).
• There is no baud rate or frame format Feature report on this chip.
  Line coding lives in a persistent 50-byte PARA_CFG parameter block
  (CMD_GET/SET_PARA_CFG, 0x08/0x09) that is stored in NVRAM and only
  takes effect "after the next power-on or external reset" (CH9329
  datasheet); reaching that config channel over UART additionally
  requires the chip's SET pin to be pulled low, a hardware line this
  cable does not expose over USB. The vendor DLL's CH9329SetCFG/
  GetCFG functions instead page that same parameter block through a
  proprietary Feature-report channel (frames 00 A1/A0 0x20),
  but nowhere issues a per-session UART rate change -- it only ever
  reads/restores the stored configuration. Sending the previous
  CH9325-style baud write into a plain Output/Input report chip like
  this one has no effect beyond risking a STALL; the meter and the
  cable both run at the CH9329's 9600 8N1 default.

Confirmed against actual hardware (including a full device scan/probe
cycle against a real UNI-T UT181A, which correctly identified the
meter and its channels/ranges over this transport).

Also added a couple of fixes to ut181a hardware (bugs & segfault).

---

Canonical usage (replace with real hidraw device):

sigrok-cli -d uni-t-ut181a:conn=hid/ch9329/raw=/dev/hidraw0 --show