Improve structured tuple struct suggestion

[camelid]

Previously, the span was just for the constructor name, which meant it
would result in syntactically-invalid code when applied. Now, the span
is for the entire expression.

I also changed it to use span_suggestion_verbose, for two reasons:

1. Now that the suggestion span has been corrected, the output is a bit
   cluttered and hard to read. Putting the suggestion its own window
   creates more space.

2. It's easier to see what's being suggested, since now the version
   after the suggestion is applied is shown.

r? @davidtwco

[davidtwco]

LGTM

[davidtwco]

@bors r+

[bors]

📌 Commit 2226977 has been approved by davidtwco

[bors]

⌛ Testing commit 2226977 with merge d19d864...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing d19d864 to master...

[rust-timer]

Finished benchmarking commit (d19d864): comparison url.

Summary: This change led to small relevant mixed results 🤷 in compiler performance.

• Very small improvement in instruction counts (up to -1.1% on incr-patched: add static arr item builds of coercions)
• Small regression in instruction counts (up to 0.3% on incr-full builds of clap-rs)

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions (either in this PR if it's not yet merged or in another PR), and then add the perf-regression-triaged label to this PR.

@rustbot label: +S-waiting-on-review -S-waiting-on-perf +perf-regression

[rylev]

The waiting on review label was added accidentally, since we're now posting perf results after merges happen. I'll remove the label.

@rustbot label: -S-waiting-on-review

The summary that this PR led to a mixed performance change seems correct though the change is quite small. We might want to tweak the perf bot to not post in such cases.

[camelid]

The perf results still seem much worse than I would have thought. The only non-error path change is that an extra Span is passed as a function argument. I wonder if these results are somewhat spurious. For example, clap-rs-opt regressed by ~0.3%, while clap-rs-debug was unchanged—but this change isn't in the optimizer, so it shouldn't have an effect on one but not the other.

@rylev Should this be marked as perf-regression-triaged then?

[rylev]

Yep - it looks spurious - all the perf changes except 2 are considered "very small" by our standards with the other two barely registering as "small" changes. Given that there doesn't seem to be a plausible explanation, and the perf change is mostly a wash, we should marked this as triaged.

@rustbot label: +perf-regression-triaged