Editor-friendly output format

[diamondburned]

This tool currently outputs both verbose and useless information directly into
stdout, which makes using this in an automated fashion seem very hard:

―❤―▶ gokart scan . 2> /dev/null
Using default analyzers config found at "~/.gokart/analyzers.yml".

Revving engines VRMMM VRMMM
3...2...1...Go!

Uh oh, a dashboard light is on! GoKart was unable to load the following packages: 
- "github.com/diamondburned/gotktrix/internal/app/emojiview"
- "github.com/diamondburned/gotktrix/cmd/emoji-uploader"

Race Complete! Analysis took 3.254922703s and 1261 Go files were scanned (including imported packages)
GoKart found 0 potentially vulnerable functions

I think it would be better for there to be a flag that makes gokart output
only the information that the user actually cares about, similar to staticcheck:

―❤―▶ staticcheck ./...
internal/gotktrix/internal/db/node.go:74:6: func convertPrefix is unused (U1000)
internal/gotktrix/internal/db/node.go:78:6: func appendString is unused (U1000)
internal/secret/secret.go:12:5: var drivers is unused (U1000)

With staticcheck's format, I should be able to trivially add this tool into
Vim.

[praetorian-harry]

Hey @diamondburned, thanks for the issue submission! We agree that GoKart does not currently have adequate support for more automated or headless use cases, and functionality such as what you've described would help to change that.

What information would you be interested in seeing in the stripped-down version of the output? For instance, a single line of output for each potential vulnerability that identifies the vulnerability type and the affected line of code? Or two lines for each vulnerability, one for the vulnerable sink and one for the untrusted input source?

[diamondburned]

What information would you be interested in seeing in the stripped-down version of the output? For instance, a single line of output for each potential vulnerability that identifies the vulnerability type and the affected line of code? Or two lines for each vulnerability, one for the vulnerable sink and one for the untrusted input source?

I think most editors will expect one line each issue, but for more verbose ones,
perhaps there could be a unique ID assigned to each that points to a wiki
explaining in details that issue.

[isp1r0]

Hi @diamondburned just want to confirm that we've added a flag, -o, --output #20

We've also created issues for adding CWE mappings to the findings
#1
as well as adding SARIF output #21

Thanks for the feedback and support!