fix: report the command output when run_cmd fails

[martin-velay]

Summary

run_cmd throws away a failing command's output and exits with its status, so a command that fails inside wildcard expansion takes the whole run down without printing anything about why.

subprocess.getstatusoutput folds stderr into its output, so that value is the only place the command's diagnostic exists. Discarding it means the message the flow author wrote for exactly this situation never reaches the terminal.

This bites any config that guards a tool behind ${VAR:?message} in an {eval_cmd}, which is the natural way to say "this flow needs VERILATOR set". Peppermint's verilator.hjson does it twice, for VERILATOR and UVM_HOME. With either unset, the whole output of a run is:

[I 260923 09:58:27 run:1048] [proj_root]: /path/to/peppermint

and an exit status of 127. --verbose adds nothing, because the message was dropped before any logging happened. Someone who forgets an export gets a silent failure and no way to find out what is missing.

With this change the same run prints:

[E 260923 14:51:11 subprocess:26] Command failed with status 127: command -v "${VERILATOR:?set VERILATOR to Verilator 5.052 or newer}"
[E 260923 14:51:11 subprocess:28] set VERILATOR to Verilator 5.052 or newer

The exit status is unchanged, so nothing downstream of the failure behaves differently.

Validation

• ruff format --check src tests and ruff check --config=ruff-ci.toml src tests pass.
• pyright --pythonpath .venv/bin/python src/dvsim/utils/subprocess.py reports no new error. The one it does report, at line 80 in run_cmd_with_timeout, reproduces with this change stashed.
• pytest --strict -q tests/ gives 426 passed. The four failures in tests/utils/test_git.py are the pre-existing ones in this workspace and fail identically on master.
• tests/utils/test_subprocess.py is new and covers three cases: output returned on success, status and diagnostic both logged on failure, and no stray empty line when the command failed without saying anything.

[hcallahan-lowrisc]

I think this is fine, but there might be a small improvement possible to dump the stdout/stderr to a file and then just tail the output into the terminal. It's possible the stdout of the failing command could be very long, so dumping all of that at once might not be ideal.
But I'm happy to come back to that as a future improvement if it proves to be inconvenient.

[martin-velay]

Good point @hcallahan-lowrisc, I have made the change, if you're happy with it you can just press the merge button

[hcallahan-lowrisc]

That looks good to me, thanks @martin-velay