### What does this PR try to resolve?
This PR expands the support for `--json-timings` (added in
https://github.com/rust-lang/cargo/pull/15780), by rendering the
individual compilation sections in the pipeline graph of the `--timings`
page.
Before, the linking section was only shown in the table at the bottom of
the page, now it should also be clearly visible in the compilation
graph, which should help more quickly understand how much time is spent
in linking.
<img width="1219" height="358" alt="image"
src="https://github.com/user-attachments/assets/71d0200d-4175-43b7-8aab-997008e2af47"
/>
I also added a legend to the pipeline graph, to explain what do the
colors mean.
<img width="338" height="118" alt="image"
src="https://github.com/user-attachments/assets/69f9bac6-c33f-44c5-8e45-afa97f314e4c"
/>
One wart is that the linking time actually ends a bit before the unit
ends, so there is some "vacuum" at the end where rustc does cleanup,
persists files to disk, deallocates things, etc. That's why I marked the
blue section "Frontend/rest" in the legend.
### How to test and review this PR?
Same as for https://github.com/rust-lang/cargo/pull/15780, e.g.:
```bash
export RUSTC=`rustup +nightly which rustc`
target/debug/cargo build -Zsection-timings --timings
```
on some crate, e.g. [ripgrep](https://github.com/BurntSushi/ripgrep).
### What does this PR try to resolve?
Had to deal with manually updating these when changing notes.
This will avoid that.
### How to test and review this PR?
### What does this PR try to resolve?
This is preparation for changes like #15917 where we start to use
`annotate_snippets::Report` for handling more of the rendering of our
user messages to be more consistent with rustc and more feature rich in
what we are able to render.
### How to test and review this PR?
### What does this PR try to resolve?
This sets up the frontmatter logic as being more standalone in prep for
- Adding a custom error type that tracks spans for a more rustc-like
error experience
- Potentially moving this out into a dedicated package
### How to test and review this PR?
### Notes
Had this sitting around for a while but haven't been able to finish the
work that builds on it so wanted this merged to reduce conflicts.
### What does this PR try to resolve?
When splitting `build-dir` out of `target-dir` (see #14125), we kept
`.crate` files as final artifacts of `cargo package`. However, that also
made them final artifacts of `cargo publish` when the side effect of
that should be the publish operation.
This changes things so that we instead package within `build-dir` and
`cargo package` then uplifts these to `target-dir`.
Behavior change: when running `cargo publish` without `build-dir` set,
`target/package/*.crate` will be moved to
`target/package/tmp-crate/*.crate`. This should be fine as its an
intermediate artifact but there is a risk that this can break someone
who did not realize that. Part of the reason for making the `build-dir`
/ `target-dir` split is to make our intermediate/final artifact intent
clearer. We did intend to be a transition period before changing things,
like with #15010. I'm assuming its fine that we don't have a transition
period here.
### How to test and review this PR?
### Notes
This was discussed at [#t-cargo > `-Zbuild-dir` and `cargo
publish` / `cargo package` @
💬](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/.60-Zbuild-dir.60.20and.20.60cargo.20publish.60.20.2F.20.60cargo.20package.60/near/537336819)
### What does this PR try to resolve?
For frontmatter parser, we almost exclusively use unit tests.
This switches the rustc ui tests we've copied over to being cargo ui
tests but in a way that makes it relatively easy to diff against rustc
and see the state of the two and makes it easier to update.
This will help as I work to improve the errors reported by cargo to
align with rustc in quality
As part of this, I made the source file auto-updating whenever new tests
get copied over.
### How to test and review this PR?
### Notes
Note: the tests are a little ahead of rustc atm, being pulled from one
of my branches that I've not yet pushed because its blocked on another
PR
