Make parse error suggestions verbose and fix spans

[estebank]

Go over all structured parser suggestions and make them verbose style.

When suggesting to add or remove delimiters, turn them into multiple suggestion parts.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[oli-obk]

Go over all structured parser suggestions and make them verbose style.

why? Most of these seemed fine to me

When suggesting to add or remove delimiters, turn them into multiple suggestion parts.

For these It makes sense

[bors]

☔ The latest upstream changes (presumably #127419) made this pull request unmergeable. Please resolve the merge conflicts.

[oli-obk]

As discussed in our 1:1, this needs a motivation and some links to annotate snippets discussions

[estebank]

The initial impetus to start this work is to facilitate the migration to annotate-snippets, which doesn't yet support suggestions, but @Muscraft is working on. Sadly the conversations were 1:1, but the gist of them is:

• a precondition for migrating is minimal changes to the output, we'll accept small divergences as long as they are reasonable, but we're aiming for 100% mimicry
• annotate-snippets is unlikely to ever support "inline suggestions"
• rustc is the one dealing with json output where these are relevant, so rustc can continue transforming suggestions into labels for annotate-snippets' sake
• Minimizing how many of the inline suggestions exist will help with the migration
• The inline suggestions were the first ones to be implemented; over time we supported multiple suggestions, suggestions with multiple parts, and rendering these suggestions with underlines for addition and replacements and a diff format for removals. I am of the opinion that the "verbose" renderings are easier to understand for people for any case beyond "add an x here" or remove this x`", particularly because suggestions where the code is similar in both cases it is easier to see the difference when presented side by side (people are already used to the patch format that diff tools use), color further aids with this. For TTS users, none of the available outputs are good.
• Making suggestions verbose is dredging up several suggestions that were incorrectly written (bad spans, using them as span_help, bad code being suggested) that were harder to spot with the inline suggestions; there are also many cases where the suggestion message is something non-descriptive like "try:", which also needs to be changed (editors can show the message without the code, so the message should be enough for someone that understands what's going on to fix their own code)

The additional commits after the one you initially reviewed are addressing your review comments.

[oli-obk]

@bors r+

[bors]

📌 Commit 71f16bd has been approved by oli-obk

It is now in the queue for this repository.

[estebank]

I'm noticing that the renderer considers any whitespace as "not there" for the purposes of deciding whether this is a replacement or addition (this is normally done to have better output), but it has the side effect of rendering not quite correctly in the face of suggestions to replace zero-width whitespace characters.