Decouple verbosity level of the logs and FD printed output

[mknorps]

Discussion started in PR #106 .

The current state is that by default verbosity level of the logger is Warning and of the tool output is a list without location details.
The coupling should be removed and probably a new cmd line tool option with a reasonable default added.

Argument by @Nour-Mws :

I couldn't but notice, however, that it introduces coupling between the overall log behavior and the details level of the report. In my opinion, whether we want or not to see debug-level log should be independent of the level of detail in our report.
I suggest:

Agreeing on a level of details in the report by default (I would prefer the less verbose one but I can be convinced to adopt the verbose one).
Having a separate --detailed option.
When printing the short report, telling the user that they can get more details by using e.g. the --detailed option.

@jherland :

About @Nour-Mws's comment on coupling this to --quiet/--verbose and their effect on the log level:

• I agree that it could be considered unfortunate for the user to also enable/disable log levels, when what they wanted was more/less detailed output.

• I would argue that if we wanted to split this into more options, then --quiet/--verbose should control the general detail level (i.e. what @mknorps is adding here, and in PR Use quiet option to display unused and undeclared dependencies #102, and that it is the log level that should get a new command-line option.

• Still, I am not convinced that it's better to add more command-line options here:

  • It forces the user to think about whether what they want more of are log messages or details. The distinction will not be obvious to a casual user.
  • When looking at other/comparable tools, I think it's a common (and expected) pattern to simply allow -v/-q to mean more/less output, without being too discerning on exactly what kind of output is meant.
  • Finally, since log messages are sent to stderr it is always (and already) possible to filter them out by redirecting stderr to /dev/null

What we decided to do for the time being:

Yes, I do agree this is not the most elegant solution, but its fix requires a rethinking of the command line tool UI. I think we agreed this should be left to users of the pre-release. Navigating between rich sets of commands and their usability, I think this coupling is an acceptable compromise.

[jherland]

PR #167 introduced new option --summary and --detailed which is used to choose between the default and the more detailed human-readable output format. These are decoupled from -v/-q, which now only control the log level.