Dualsense Bluetooth CRC check

When reading a Bluetooth report for the Dualsense gamepad, we ignore the CRC check. If there is a lot of noise, the data we receive could be invalid. We return the last available data regardless of this check.

We repeatedly read from the device to avoid a buildup of latency (also look into why this is the case), and we override (and erase) the last state. To solve this there must be a second buffer.

Either we always read to one buffer, memcopy if the data is valid, and return that buffer. Or we switch between the two buffers, swap the reference if the data is valid, and return the last written buffer unless it is invalid.