Add option to hide build command on compilation error to build_runner

[leecannon]

I know #6673 is still open with no consensus for the long term improvement of cli errors, but with a project with a large number of C files added you get errors like this (~36,000 characters of build command) which is just actively hostile to a nice debugging experience.

This PR is a stopgap that is not intended to be permanent which adds hide_build_command_on_error: bool on builder and --hide-build-command-on-error command line argument when using zig build

The scope of this change is kept small with the flag only taken into account in execFromStep when encountering a ExitCodeFailure as this is the path that a normal failed compilation will execute, rather than checking this flag everytime a failed command is to be printed e.g. on file not found.

[andrewrk]

Rather than --hide-build-command-on-error I suggest for this feature to be named after the actual goal: surface compile errors. The implementation can be the same as this stop gap solution for now, but it allows room to improve the feature to do the following:

• Detect compile errors and present only them
• Still print the build command as usual if a non-compile-error crash happened

Counter proposal: --prominent-compile-errors
Description: "Indicate the purpose of executing the command is for a human to read compile errors from the terminal"

In the future there will be other options that make the output more consumable by an IDE and other tooling, so we want to be sure to make clear the niche this flag serves.

[leecannon]

Does it make sense for it to be the other way round?

i.e. zig assumes without any additional flags that its output is for human consumption and requires additional flags for more detailed output for use by tooling, compiler troubleshooting, etc.

[andrewrk]

Description: "Indicate the purpose of executing the command is for a human to read compile errors from the terminal"

There are 2 components here, not just 1:

• human, not computer, is the agent
• the intended purpose is to read compile errors

The default use case is:

• if detected a TTY, then it is a human, otherwise it is machine
• intended purpose is to silently succeed the build, or loudly fail with all the information needed to troubleshoot a problem anywhere on the process stack.

[leecannon]

Im not 100% happy with the description of the flag in the usage text

--prominent-compile-errors   Output compile errors formatted for a human to read