Tolerate sensors that do not ACK every command

[nikicat]

Every Device method assumes the sensor sends an ACK frame before the reply:

if isinstance(self.protocol, protocol.USBProtocol):
    check_ack(
        check_message_protocol(
            check_message_pack(self.protocol.read()), COMMAND_ACK),
        COMMAND_FIRMWARE_VERSION)

That assumption does not hold for every device. 27c6:533c (GF5288_GM168SEC, tested on a Dell XPS 13 9310; the same USB ID is also reported for the XPS 13 9300 and XPS 15 9500) ACKs reset and read_sensor_register but answers firmware_version and enable_chip with the reply alone. The unconditional read then consumes that reply, fails to parse it as an ACK, and the command errors out on a perfectly healthy sensor:

firmware_version() -> ValueError: Invalid message protocol
enable_chip(True)  -> USBTimeoutError: [Errno 110] Operation timed out

The change

Device._expect_ack() reads one frame and, if it turns out not to be an ACK, puts it back via self._pending so Device.read() hands it to the caller as the reply. The 25 self.protocol.read() call sites became self.read() so they see the pushback.

Sensors that do ACK are unaffected — the ACK is consumed and verified exactly as before. The change is strictly more permissive, so nothing that works today should change.

It also collapses 31 five-line blocks into one-liners: net −88 lines.

Verification

On 27c6:533c, all six commands now succeed where two used to fail:

command	before	after
nop	OK	OK
enable_chip	USBTimeoutError	OK
firmware_version	ValueError	OK — GF5288_GM168SEC_APP_13016
reset	OK	OK — (True, 1024)
read_sensor_register	OK	OK — 0c a1 00 22
read_otp	OK	OK — 68 e6 86 4a 54 ec 15 04 ...

I only have a 533c to test against, so a sanity check on a device that does ACK everything would be welcome.

Unrelated bug spotted

goodix.py:341 in write_sensor_register has for i in length where length is an int — presumably range(length). Left alone here to keep this PR to one concern.