Add guidance about documenting FnMut order

[scottmcm]

Inspired by rust-lang/rust#60396, I was pondering if it would be good to have something like

If you take a parameter that implements FnMut, document the order in which it will be called, as it encourages callers to use stateful closures that may make changing the order a breaking change.

[Centril]

It seems to me this isn't specific to FnMut. Really, any side-effect counts.

Documenting the order can also over-commit to an implementation that you may want to change later for assorted purposes (optimization, ...). However, I think if you want to not commit to an order, it would be best to document the non-commitment.

[scottmcm]

Yes, there's definitely the contrapositive that if you don't want to commit to the order you should consider only accepting Fn instead.

[Gankra]

You shouldn't be changing what Fns you take in that way. Fn can mutate things with interior mutability (RefCell/Cell/Mutex, etc). The names are to help out a bit with intuition, but the real meaning of the Fn traits in bounds is how they're used:

• FnOnce: I only need to be able to call this exactly once
• FnMut: I need to be able to call this multiple times
• Fn: I need to be able to call this multiple times in a way that precludes mutual exclusion (re-entrancy, concurrency, etc.)

(Fn is almost completely unused in bounds, since that's a pretty specific scenario)