Document SemVer hazards of spi::Operation::DelayNs

[GrantM11235]

Imagine this timeline:

• A driver author releases cool-driver 1.0.0 which uses SpiDevice but doesn't use DelayNs.
• A user uses a SpiDevice impl from embedded_hal_bus with NoDelay. The user tests it and it works fine.
• The driver author notices a timing problem and adds a DelayNs and releases it as cool-driver 1.0.1
• The user updates cool-driver (maybe even by accident). It still compiles with no warnings.
• The program panics at runtime.

Aside from making actual changes to the SpiDevice trait, I can only think of two possible "solutions":

1. Tell the author of cool-driver that by adding a DelayNs they have made a breaking change and they must release it as version 2.0.0 instead.
2. Tell the user that they shouldn't really use NoDelay, but if they do they must pin the version of any dependency that they use it with.

I don't really like either of these options, but I don't have any better ideas.

[Dirbaio]

opened #558 to address this. It picks solution 2, which is sort of what we agreed on when we added the "no delay" versions: it's theoretically semver-breaking but in practice it's going to be rare that a driver starts using delays if it wasn't before.