[RFC]SPI: Fix dumping

[CTCaer]

Commit https://github.com/shinyquagsire23/HID-Joy-Con-Whispering/commit/e72e8b9ef43bdce5d778ba9ea463b6c464e8b2ba broke SPI dumping by removing the command that tells the device how much data to return back. The request was a 0 length data, so the device was replying back with a zeroed data in packet.

This adds back the data length and implement a structure for changing the length data size. It has only options:

1. safe_length: SPI flash is 512KB. 32768 16Bytes fit exactly in 512KB
2. fast_rate_length: Uses the maximum data allowed for SPI in a packet. You need to trim the last 3bytes from your dump

[CTCaer]

By the way, I see inconsistencies for the first bytes of the dump. This happens with all commits of this program.

Most times when connecting the grip, the first bytes are zeroes. But when restarting the program, without re-plugging joy-cons and grip, it dumps "correctly" and the 1st 4 bytes are 0108 00F0.

The zeroed bytes are actually the length of the spi read. So, it seems that the Joy-cons fail to reply correctly for the 1st packet.

[shinyquagsire23]

I'll try and take a look at this later today, I had a pending SPI change I forgot to push but I'll do some comparisons probably.

[CTCaer]

The most important thing here is spi_read[0x4]=data_rate; And maybe that in my tests through USB and BT HID, I found that maximum SPI read is 0x1D.

I am finishing a code for async dual dumping support now, that also has some clean up for these commits. For example, the spi_read[0x4] is out of the loop above it, because no need to apply it every time. And removed 0x10 SPI read and added code to strip last 3 bytes.

So this PR is RFC for anyone that needs a working SPI read right now.

[shinyquagsire23]

I'll go ahead and merge I guess, will probably be doing more refactoring myself once the weekend is here.