Capture per-crate build timings from cargo's --timings output

[oriongonza]

Summary

Closes #812.

Depends on #824.

When capture_timings = true in config.toml and the toolchain is nightly, crater now passes --timings to cargo and captures the per-compilation-unit timing-info JSON messages. Each entry records the package, target, mode, duration, and rmeta time. The data is stored in a build_timings SQLite table keyed by (experiment, crate, toolchain).

This gives crater the infrastructure to collect rough per-crate build durations alongside every run, and discussed on Zulip (#t-infra > crater get rough perf numbers). The data is not surfaced in reports yet, so future work is needed.

Motivation

Several use cases came up in the discussion:

• Compiler optimization guidance: detecting large compile-time regressions (e.g. 6x–30x slowdowns from trait solver changes) that currently go unnoticed until users report them.
• Ecosystem visibility: sites like lib.rs could eventually attach "expected build time" data to crates.
• User-facing data: answering questions like "how much does extra LOC add to compile time".

Crater's environment is noisy (oversubscribed machines, non-deterministic build order, cache effects), so these numbers are rough, but rough timings are better than no timings :D

[Mark-Simulacrum]

Are the majority of the changes here (in particular the comments) generated with some LLM tool? I don't want to accept those changes at least (they aren't related to this PR and I'm not a fan of generated comments, that feels broadly unhelpful and would take a good bit of review bandwidth).

I haven't looked at the actual changes but I'm pretty sceptical we would want to store any extra information into crater's database. The approaches I've discussed with others broadly speaking leave the output in the files sent to S3 and analysis external; I'd prefer to keep it out of the crater codebase until we are least have evidence there's enough signal to noise ratio for it to be valuable.

[oriongonza]

Are the majority of the changes here (in particular the comments) generated with some LLM tool? I don't want to accept those changes at least (they aren't related to this PR and I'm not a fan of generated comments, that feels broadly unhelpful and would take a good bit of review bandwidth).

Rebased. Feel free to leave the other PR open, no hurry. I didn't think that it would be a controversial change.
As explained in #824:

My position is that robot docs that are correct and present are better than artisanal docs that don't exist yet — and these didn't exist yet

[oriongonza]

I'm pretty sceptical we would want to store any extra information into crater's database

1. This is behind an off-by-default setting
2. The fact that it's in a database is very nice because you can actually use SQL queries to ask questions: "how long did serde take to build in this version of the compiler?"