Fix data extraction in run_tap_command to handle potential length/sta…

[pkkid]

This fixes issue #5.

Modified the run_tap_command function to handle TAP command responses more robustly. The function now checks whether the device prepends a non-printable length/status byte before the actual string data in the response.

• Previously: The code assumed data started at index 1 (after report ID)
• Now: The code checks if the first byte is non-printable (outside ASCII printable range 0x20-0x7E)
  • If non-printable: Skips it and starts reading from index 1
  • If printable: Assumes data starts immediately at index 0

This change accounts for the fact that hidapi's get_feature_report() on Linux strips the report ID from the response, and different devices may format their response data differently.

Before:

> sudo ./bose-dfu info
USB serial: 00000000000000000000000
HW serial: 77049990530131A1
Device model: Cup
Current firmware: .1.4.3558

After (first character is displayed):

> sudo ./bose-dfu info
USB serial: 00000000000000000000000
HW serial: 077049990530131A1
Device model: KCup
Current firmware: 1.1.4.3558