Command runner logging enhancements with `--debug`

[JeffreyCA]

One current limitation of the command runner implementation is that when running azd with --debug, if the command being executed takes a very long time or appears to be stuck, neither the command or output gets logged until the process exits.

---

Originally posted by @weikanglim in #5501 (comment):

Right now our command runner only logs the full output of the command after execution:

2025/07/17 19:22:52 command_runner.go:310: Run exec: 'git --version' , exit code: 0
-------------------------------------stdout-------------------------------------------
git version 2.45.3

A possible enhancement is to split this out into two messages:

2025/07/17 19:22:52 command_runner.go:310: Start: 'git --version'
2025/07/17 19:22:52 command_runner.go:310: Stop: 'git --version' , exit code: 0
-------------------------------------stdout-------------------------------------------
git version 2.45.3

---

A further enhancement could be to support streaming the command output in real-time, which would make it easier to observe and debug cases like #5491, where the command being executed initiated a long-running process:

info: Microsoft.Hosting.Lifetime[14]
      Now listening on: http://localhost:5241
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /workspaces/junk_20250716/Something

[weikanglim]

re: streaming -- I'm wondering what treatment we would apply to when streaming from both Stdout and Stderr of the shelled out process. I didn't figure out a great way to do this without resulting in message interleaving between the two streams being a source of potential confusion.

In the past, it has been somewhat useful to have stdout and stderr printed out separately in the debug logs, since this may be useful to understand what azd was observing from the process after it exited. We often parse stdout/stderr in azd to parse out output/specific error conditions of the external tool.

[JeffreyCA]

Good point, I was thinking we could prefix the output with the timestamp and whether it's coming from stdout/stderr, but I can understand the trade-off between separating the two in the debug log and interleaving them to support streaming.

Copilot said it should still be possible in the streaming approach to capture the two separately for parsing output, errors, etc. after execution.