Expose all the CS signals (The SPI hardware can take multiple CS pins and turn them on/off for each transfer. Software CS shouldn't be the long term solution for shared buses)

[bjoernQ]

No description provided.

[bugadani]

We should probably expose a sort-of CS allocator. Devices should be able to request "CS tokens" (which essentially just stores the number of the CS signal) from the SPI driver, and the SPI driver should expose a setting to configure which CS token is in use, along with KEEP_CS_ACTIVE (#2797).

Something like:

let cs = Output::new(...);
let cs_token = unwrap!(spi.allocate_hw_chip_select(cs));

let device = SpiDevice::new(&spi, DeviceConfig::default().with_hardware_cs(cs_token)); 
// OR:
let device = SpiDevice::new(&spi, DeviceConfig::default().with_gpio_cs(cs));

This would mean a slight inconsistency in terms of how we set up a peripheral signal, but it also prevents routing a chip select to multiple outputs by accident. Since we don't clear existing peripheral output signal connections, that would be all too easy to do with just calling .with_cs0() multiple times.

[MabezDev]

Given that we're marking the current with_cs hardware cs method as unstable, and we're not planning on having our own hardware managed SpiDevice impl for 1.0, I'm dropping the label.

FWIW, I like @bugadani's suggestion and I think we'll likely take that route when it comes to implementing this.

[Dominaezzz]

This would mean a slight inconsistency in terms of how we set up a peripheral signal, but it also prevents routing a chip select to multiple outputs by accident. Since we don't clear existing peripheral output signal connections, that would be all too easy to do with just calling .with_cs0() multiple times.

Now that #3012 has landed, we can just have a simple with_cs0, with_cs1, with_cs2, etc.
The Config could also store a bitmask of which CS pins to enable/disable, nice and simple.