We should have a consistent way of talking about rules to follow vs Actual Unsoundness

There are a lot of things which are _nice_ rules to follow, that do not necessarily imply unsoundness. For example, https://github.com/rust-lang/unsafe-code-guidelines/issues/346, https://github.com/rust-lang/unsafe-code-guidelines/issues/77, and https://github.com/rust-lang/unsafe-code-guidelines/issues/395 are some tricky subjects where UCG may rule on something that balances practicality, the preexistence of unsafe code, and the sanctity of the model, to end up with something very subtle. However, from _our_ point of view, we are free to provide stricter (but _clean_) rules provided we are very clear that the actual thing is not as strict. For example, "just never have `&uninit`" is a rule that is decent to hold and can be followed, but with the current direction the winds are blowing, there will be many scenarios where that is actually okay, and when _auditing_ code this might be passable.

This doesn't have to do with yet-to-be-ruled UCG issues either, in general we can Postel's law our recommendations where possible.

We should probably:

- Have a separate chapter talking about UCG , Postel's law, and how we plan to talk about this
- Use consistent language when talking about this

We want this book to be practical for the purposes of both writing and auditing code, and being super clear here would be great.