Add tools for perf analysis

[desiderautumn]

This commit adds tooling for analyzing the performance overhead of spawning subprocesses. See src/perf/README.md for documentation.

Example output on Linux (of cargo run diff @..f296d):

Time spent in each command:
    /usr/bin/git: 2341 ms (1028 calls)

Time spent in each git subcommand:
    blame: 756 ms (113 calls)
    cat-file: 566 ms (339 calls)
    rev-parse: 344 ms (232 calls)
    notes: 296 ms (227 calls)
    diff: 195 ms (3 calls)
    ls-tree: 183 ms (113 calls)
    show: 1 ms (1 calls)

Total time spent in spawned commands: 2341 ms

Total program time: 3461 ms

Total program time not spent inside commands: 1120 ms (32.36%)

On Windows:

Time spent in each command:
    C:\\Program Files\\Git\\bin\\git.exe: 22890 ms (1028 calls)

Time spent in each git subcommand:
    cat-file: 7451 ms (339 calls)
    rev-parse: 5028 ms (232 calls)
    notes: 4827 ms (227 calls)
    blame: 2745 ms (113 calls)
    ls-tree: 2502 ms (113 calls)
    diff: 314 ms (3 calls)
    show: 23 ms (1 calls)

Total time spent in spawned commands: 22890 ms

Total program time: 24843 ms

Total program time not spent inside commands: 1953 ms (7.86%)

---

[CLAassistant]

All committers have signed the CLA.

[devin-ai-integration]

Devin Review found 1 potential issue.

View 3 additional findings in Devin Review.

[devin-ai-integration]

🟡 README typo: measured_stats should be measured_status

The README on line 7 refers to the wrapper as measured_stats, but the actual trait method is named measured_status (as correctly documented on line 12 and implemented in src/perf/mod.rs:13). This will confuse developers trying to use the API based on the README.

Suggested change

	via the `measured_output` and `measured_stats` wrappers.
	via the `measured_output` and `measured_status` wrappers.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[svarlamov]

@heapwolf See if you'd like to merge or cherry-pick from here for any perf stuff -- esp for Windows. Ideally we can have a harness that would live inside our codebase for easy profiling