Added two new constructors to ExclusiveDevice to allow for SPI devices that don't require a CS pin

[uliano]

Summary

• Introduced NoPin (in embedded-hal::digital) as a dummy pin for hardware-managed CS scenarios.
• Added two new constructors to ExclusiveDevice, namely new_no_cs and new_no_cs_no_delay (could't figure out any better) to allow for SPI devices that don't require a CS pin.

Why?

The existing implementation required an OutputPin, which for some chips can be unnecessary and effectively wasted.

Edited

I refactoerd this PR along the lines hinted by @Rahix below.

[uliano]

About the use case if there is such a thing as an exclusive device that needs to control its CS for some reason (can't figure out any) it can be done with an additional OutputPin to be contolled as required.

But then it should be proved that such a case exists.

To me this has been oversighted.

To be follwing to the letter the naming found here

Module spi

It should have been named ExclusiveBus from the beginning (but then all the Buses are Exclusive so still redundant)

About the breaking change, I normally quite agree with you. Here my reason for that is that the name of this SpiDevice implementation is contradictory and misleading. Is it better to have users correct their code (just remove the pin) or to keep a misnomer in the Interface?

Convenience (your proposal) but still one should take the fuss of making its own NoPin

or Correctness (my PR)

I sincerely can't decide

[Dirbaio]

there's many SPI chips that need CS toggles for each transaction, so they know where a command begins/ends, and they don't work if you tie CS permanently low.

[uliano]

there's many SPI chips that need CS toggles for each transaction, so they know where a command begins/ends, and they don't work if you tie CS permanently low.

I see, then @Rahix is the only choice.

I see what I can do along that approach

[uliano]

@Rahix @Dirbaio. I refactored the PR along the lines of @Rahix suggestions above. Now the NoPin behavior is opt-in.