SPIClass::transfer(void *buf, uint16_t count) transfers with wrong block structure

concerns spi.cpp, lines 309 to 329

The current algorithm of void SPIClass::transfer(void *buf, uint16_t count) is
- repeat until buf is 32bits-aligned: transmit a single bytes using SPIClass::transfer(uint8_t data), increment buf and decrements count. This could occur up to 3 times.
- transmits multiple of 4 bytes via SPIClass::transferBytes(const uint8_t * out, uint8_t * in, uint32_t size). transferBytes() splits data into 64 byte blocks.
- transmit the remaining bytes (up to 3) as single byte transfers using SPIClass::transfer(uint8_t data)

If you use hardware CS there is the following problem. Mention, you *must* use hardware CS if you use the altenate pin configuration (hspi overlap):

After each transfer CS goes HIGH and LOW again. So, using transfer(void *buf, uint16_t count) you dont have a single block transfer. There are lot of tranfers with different sizes. In worst case: 3 single byte transfers, some 64 Byte transfers, 3 single Byte transfers.

You one can not avoid that this happens after every 64 bytes, because the IO buffer is only that long. But up to 64 bytes only a single block should be transferred.

The call sequence is:
```
transfer(void *buf, uint16_t count) (establishes 32 bit aligment)
|
+--> transferBytes
|
+--> transferBytes_ (establishes 32 bit aligment too)
|
+--> transferBytesAligned_
```
You see, there is no need for method "transfer" to make a 32 bit alignment. This is done by "transferBytes_" (with underline at the end) anyway later. The algorithm of "transferBytes_" is much better. It transfers in 64 Byte blocks.

Please replace the code if "transfer" to a simple call to "transferBytes":
```
void SPIClass::transfer(void *buf, uint16_t count) {
transferBytes(reinterpret_cast(buf), nullptr, count);
}
```