Mixing synchronous and asynchronous SPI APIs may be dangerous

Suppose the following sequence is executed:
1. Set chip select low for peripheral A
2. Post an asynchronous transfer for peripheral A
3. Enter a peripheral driver for peripheral B (before the transfer to A completes)
1. Set peripheral B's chip select low
2. Send a byte to peripheral B
3. Set peripheral B's chip select high
4. On completion of the asynchronous transfer, set chip select high for peripheral A

In this sequence, an SPI transfer has started when the chip select for peripheral B is set low, which will cause peripheral B to receive incorrect data. It will also cause a contention between the MISO lines on peripheral A & B.

Typically synchronous SPI drivers manage the chip select without checking the state of the SPI peripheral. This will make it very difficult to make a driver-internal change to correct this behaviour.

Possible solutions:
1. An SPI peripheral can be configured as one of synchronous or asynchronous at any given time. A mechanism like `acquire()` will need to be used to prevent both from existing simultaneously.
2. The synchronous API can be deprecated
3. The synchronous API can be changed to require the chip select to be managed through the SPI peripheral (e.g. with a setCS() and clearCS() API). This would allow the SPI peripheral to block while waiting for asynchronous APIs to complete.

Start by reviewing the synchronous and asynchronous SPI API entry points and how each manages chip select. Compare the three proposed approaches in the issue, then define the selected API behavior and verify that mixed transfers cannot overlap or create chip-select and MISO contention.

Written by the indexing model from the issue text.