Convert notes to helps in the compiler

[brson]

#16855 adds span_help and help diagnostic types, distinct from note. A significant number of notes are actually helpful suggestions and need to be converted.

[brson]

My notes from the PR:

I scanned the source for notes that might be candidates for help and found these:

• "having upstream crates all available in one format will likely make this go away"
• "consider removing this semicolon:"
• "consider changing this closure to take self by mutable reference"
• "closures behind references must be called via &mut"
• "type aliases cannot be used for traits"
• "call the method using the . syntax"
• "Did you mean to write: {} {{ /* fields */ }}?"
• "consider using an explicit lifetime parameter as shown: {}"
• "use "#[unsafe_destructor]" on the implementation to force the compiler to allow this"
• "add #![feature(default_type_params)] to the crate attributes to enable"
• "the trait {} must be implemented because it is required by {}"
• "the trait {} must be implemented for the cast to the object type {}"
• "the Copy trait is required because the repeated element will be copied"
• "all local variables must have a statically known size"
• "the left-hand-side of an assignment must have a statically known size"
• "structs must have a statically known size to be initialized"
• "cannot implement a destructor on a structure or enumeration that does not satisfy Send"
• "use "#[unsafe_destructor]" on the implementation to force the compiler to allow this"
• "the closure that captures {} requires that all captured variables implement the trait {}"
• "only the last field of a struct or enum variant may have a dynamically sized type"
• "did you mean &{}{}?"

... well, there are a lot.

Some notes combine both contextual info and suggestions and might be separated:

• "{} moved here{} because it has type {}, which is moved by default (use ref to override)"
• "{} moved here{} because it has type {}, which is moved by default (use ref to override)"

[ftxqxd]

I’m working on this, but I think we still need to further clarify what counts as a help message rather than a note. If something directly suggests the user to do something (e.g., use ref to override), I think that definitely qualifies as a help message. If something just adds information to an error (e.g., reference must be valid for the block at 1:10), it should clearly be a note. But sometimes it’s not so easy to tell. Messages like type` aliases cannot be used for traits` _explain_ an error, but they don’t suggest what to do. So should they be notes or help messages? On one hand, it makes sense for them to be help messages, as they _help_ the user understand the main error message, but on the other hand, they are in a way part of the error. In a message like `expected `;`, found `{, it would be strange to separate the expected ;`` part into a help message, but it does only provide extra helpful information to explain the error.