Display errors from go command

First of all, thank you for this amazing project

Consider the following command:
`cyclonedx-gomod mod -verbose=true -json=true -assert-licenses -licenses=true -output "/tmp/sbom/core.json" core`

You can see thanks to `-verbose=true` the go commands that `cyclonedx-gomod` runs behind the scenes:
```
5:30PM DBG executing command cmd="/usr/local/go/bin/go mod why -m -vendor github.com/CycloneDX/cyclonedx-go" dir=core
5:30PM DBG loading vendored modules includeTest=false moduleDir=core
5:30PM DBG executing command cmd="/usr/local/go/bin/go mod vendor -v -e" dir=core
5:30PM DBG filtering modules includeTest=false moduleCount=207 moduleDir=core
...
```

I have a process that runs non-interactively to produce the SBOMs. When it failed, I accessed the machine it ran on, but the same behavior could not be reproduced. This is because when the shell is running interactively, it changes its behavior in several ways: https://www.gnu.org/software/bash/manual/html_node/Interactive-Shell-Behavior.html

My method to troubleshoot this issue was to run the cyclonedx-gomod command in the interactive session (which succeeds) with the `-verbose` option, to see which go commands it is running, and to add these go commands to my non-interactive workflow. By running `go` without cyclonedx, I could see the actual error I ran into, which was very simple and caused by the difference in environment variables present in the interactive vs. non-interactive session: `go: github.com/google/gopacket@v1.1.19: neither GOPATH nor GOMODCACHE are set`

Currently cyclonedx-gomod doesn't show the errors from the `go` commands it runs:
```
ERR error="failed to download modules: command `/usr/local/go/bin/go mod why -m -vendor github.com/CycloneDX/cyclonedx-go` failed: exit status 1"
```
I think it would be a great help to people who use this project if they could see what went wrong behind the scenes rather than just seeing "go exited with error code 1".

I looked at the `-help` files for cyclonedx and I didn't find anything like this, let me know if I missed it, and if it doesn't yet exist please consider adding it. Thanks

Start by locating the code that runs the go commands shown in the issue and inspect how command failures are converted into the current exit-status-only error. Trace the existing error path, then identify the relevant tests or add coverage for preserving the go command's stderr; done means users can see the underlying error, such as the missing GOPATH or GOMODCACHE message.

Written by the indexing model from the issue text.