Allow multiple chip selects in crossbar

[thirtythreeforty]

This PR adds support for forwarding one or more chip selects from a client out to multiple output CS lines, while still arbitrating use of the shared MOSI/MISO/CLK lines and PHY.

Since each client may care about a different physical CS line or set of CS lines, these are passed in to get_port():

  output1 = xbar.add_output_cs()
  output2 = xbar.add_output_cs()
  user_cs = Signal(2)
  port = xbar.get_port(user_cs, output_cs=Cat(output1, output2))

(The default is to continue to use self.cs to preserve existing behavior.)

My use case is that I will have an autonomous (edge triggered) SPI master that reflects status signals from RTL onto GPIOs on a SPI expander, and a memory-mapped SPI flash. If this approach is good, I'm open to how you think this could be cleanly extended up into the chipselect register exposed by SPIMaster.

I also added unit tests for the existing behavior of the crossbar and master. Feedback is desired here because I don't feel like they're super idiomatic, but I wanted something in place before I really started making changes.

[thirtythreeforty]

Hmm, perhaps this should be get_output_cs to match get_port?

[thirtythreeforty]

I think a little more work is needed to forward the chipselects thru to the hardware.

This raises the question of how to do this ergonomically.

The platform description could have multiple chipselect lines, such that cs_n is a multiple-pin "bus." Then the crossbar and all the layers in between can refer to chipselects primarily by their number.

This idea makes it difficult to name chipselects by platform.request like it is done for most other signals.

Each additional chipselect could be presented in the platform as its own GPIO. However then it's unclear exactly why cs_n should be "special" (what makes SPI flash more important than a SPI ADC for example). It's also unclear how to pass them to the phy and map those to the crossbar's signals.

Additional ideas are welcome!