* Okay so I'm kinda back in the position of not liking the current solution re Spi sharing again :P

I've been trying to prove out the design by using it in `display-interface` but it's super cumbersome. To explain more, `display-interface` currently only provides a `WriteOnlyDataCommand` trait. This trait can be implemented fine using only `SpiDevice`. But if we want to implement reads in the future we'll run into the problem of wanting to change DC during a transaction. So now we want to be able to implement `WriteOnlyDataCommand` both for any underlying `SpiDevice` impl which we wrap into a `SpiDeviceInterface` trait along with our `DC` pin, but also for some kind of `SpiSharedBusInterface` struct, which internally holds any of `&RefCell<Bus>`, `&Mutex<Bus>`, etc.

So we want a way to abstract over such an internal "shared\<Bus>". But we don't want to do it in a "display-specific way" we just want a way to say "give me the underlying `SpiBus` impl, please. Making it display-specific defeats the point becuase we're already in the process of implementing the high level display-specific interface (let's call it `ReadWriteDataCommand`) in a more concrete way through Spi. So now again I want a `SharedBus` trait.... which I could add directly in `display-interface-spi` crate, but it feels too generic for that and would be useful to have unified in the ecosystem.

Would you be more amenable to including such a thing within `embedded-hal-bus` rather than in `embedded-hal` directly? dirbaio