Add status and error column to non-human output for all applicible subcommands

[davidnuzik]

Summary: I propose we add a status column to each applicable subcommand (remediate already has this) as well as an error column.

The purpose is to represent when an error may have happened while processing any file or directory with any of our applicable subcomamnds (vuln-scan, malware-scan, remediate). This is especially useful since --allow-io-errors is set by default for applicable subcommands. This enhancement is useful so that by default scans do not just fail/abort (which could be painful/annoying in situations where many thousands of files are being scanned). The current trade off is that if the user (today, v3.0.1 or older) wants to be alerted on such errors the scan must abort/fail without summary output and otherwise completing the scan. This enhancement should permit the use of --allow-io-errors (default) while still being alerted on any such errors during a scan via non-human output.

For example, with this functionality, the end-user can opt to include status and error columns in their output so that they can see if the CLI encountered any errors while trying to process a file or folder on disk. The status can be similar to what we have with remediate presently. It should include a value error and this value will be written to the output in this column if the file or folder could not be processed. The error column (or perhaps error-description column?) will output the error we encountered.

Thoughts/Considerations:

• We only output files in all output currently, not directories. If we have an error on a directory (such as file permissions or I/O error) we should still log this in output, but if we do this will change prior behavior which only included files in output. Ultimately I think this is probably not an issue, but if anyone is just counting lines in output an entry for a directory could be considered a file. I think that this is okay -- the user should be responsible and be aware of updates we make over time. If we are particularly concerned we could add an option such as --output-files-only or something, but this is adding yet another argument to an already long list of options; we should consider if we really want to add such an option.
  • Additionally, an --output-files-only option will potentially hide permission / I/O / other errors the user should see on directories. If we do want to add such an option we should ensure it's clear that they won't see errors on directories (if any) in output. I am just concerned because in my opinion it would be unwise to use such an option 99.9% of the time. I'd rather the user have to alter / sed the file to take out any directory entries if they so wanted for some reason.
• Do we just want to add status to each applicable subcommand instead of it plus error column? If we do, it will be one less column, instead of a separate column for error description our status could now be something like "Error: {description}". The advantage is reducing column count, the disadvantage is less control for the user (so my thinking is we probably want both columns; I just wanted to share this thought for consideration).
• Optionally the status column could have various values for when issues occur such as log levels of criticality "warning" or more severe i.e. "warning", "error", "critical" rather than just a status "error".
• If we are to output the full description of the error to either the "status" or "error" / "error-description" columns we may want to set a max chars limit -- perhaps as low as 128 chars or something -- this way any output does not have extremely long text for any one cell. In such cases when the error string exceeds this count of chars, the user should simply try to scan the specific directory/file to intentionally cause the error at which point they can read the entire error output.