doc: Clarify constraints

[chrysn]

This improves the documentation in a few places where I think it is lacking, in particular (sorted for expected most controversial to least controversial):

• States that the Nor types are duck-named in the sense that they don't necessarily require actual NOR flash to back them, but just the described semantics to be upheld.
• Rephrase the read error description (and the capacity) to make it clearer that not only the address being read from needs to be aligned, but also the length.
• WRITE_SIZE and ERASE_SIZE: This is not a minimum, but an alignment
• write: Point out that the write-once behavior can be (and is) overridden by another trait
• Document Rmw...NorFlashStorage

There is one change I'm tempted to make but I'm not sure what to change it to, i.e., what the intended behavior is:

On MultiwriteNorFlash, what happens if the application attempts to write something that does not have the bits cleared that are already cleared?

• The implementation must ensure that the resulting data is AND-ed
• The implementation must produce an error
• The implementation may do either
• The implementation may do either, or may write the argument unmodified

If this passes review, I'll copy the changes over to the async equivalents, which AIU have identical APIs.

[eldruin]

Thank you!
Any comments @MathiasKoch ?

[MathiasKoch]

Not sure how I missed this even after being tagged. Sorry about that.
Looks great to me 👍

Could you add the same to async?