librustdoc: more impl fmt::Display

[yotamofek]

Continuation of #137425 and #136828 and #136784
Working towards getting rid of the write_str helper
r? @GuillaumeGomez (if you want!)

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

[yotamofek]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged. Otherwise, you can ignore this comment.

This is intentional, I'm pulling in latest version of either with impl fmt::Write for Either (cc & thanks @jswrenn and @cuviper)

[yotamofek]

Perf is neutral locally, but I'll request a run on CI just to be sure.

[GuillaumeGomez]

Not sure this change is good considering we need to allocate a string in any case but relying on format!.

[yotamofek]

I think this will end up behaving exactly the same. It will construct the string piece-by-piece.
It would only matter if we used String::with_capacity, otherwise .pushing into a string directly, or using format!(), are the same in terms of reallocations and such.
(maybe I'm missing something?)

[GuillaumeGomez]

Same in this file: I don't expect any improvement in performance considering it's always pushing into a string and it makes the code more complex.

[yotamofek]

The point of this PR in itself isn't performance.

My end-goal is to try to make ALL the rendering lazy, and then we could ideally write into a BufWriter that wraps the actual file, instead of writing everything to a String first, and then to the file system.
I do believe that that would be good for performance, because it should minimize the number of reallocs needed for rendering a single file. And maybe we could reuse the underlying buffer from BufWriter, which would be even better.
But such a change would be huge and I don't want to do it in one PR, so in the meanwhile I'm trying to put out small PRs that make progress towards that goal without hurting performance - so this PR being neutral in a perf run would be a success, as far as I'm concerned.

I also want to get rid of that write_str helper I introduced in #136784, since it's very verbose (because it needs format_args!()) and I intended it as a stopgap measure.

The only change to the code in this file (if you view the diff w/o whitespace) is the fmt::from_fn() and extra indentation it causes, which isn't great, but I think that the removal of all the format_args!() makes up for it. That's just my personal opinion, of course :)

Anyways, if you don't like the direction I'm going in let me know, and, obviously, feel free to close this PR if you think it's not improving the code at all! I'm thankful for the time you put into reviewing all my PRs 🙏

[GuillaumeGomez]

I'm fine with the rest of the changes. In highlight.rs though a bit less.

[yotamofek]

I undid the unrelated changes in highlight.rs, let me know if it's better now.

[GuillaumeGomez]

Sorry but still the same, for now I only see it as a code complexity increase for no gain. ^^'

[yotamofek]

Sorry for the delay, was traveling 😁
Undid the changes in this file, will figure it out in the future.