Add user-configurable level logger

[cgrindel]

Add a level logger to the CLI. (I believe that I used zap in a previous life.) When problems happen in the field, we can ask them to enable logging and ship us the resulting log file. I would add two flags: --log_level and --log_output. The log level would default to error. The log output would default to none. Other options for log output would be stderr and a file path.

[cgrindel]

Alternative mode of operation:

• Always log; would need to add log rotation logic.

[cgrindel]

@f0rmiga I am suggesting that we leverage zap as the logging framework. Do you have any thoughts on other logging frameworks that we should consider?

[f0rmiga]

My preference is github.com/sirupsen/logrus, which we use in our private repo already. Though, any logging should use an interface instead with a private implementation that wraps the real logging framework, so it's easy to swap. I'll send a private reference to this over Slack.

[cgrindel]

I did not recommend logrus, because it is in maintenance mode:

Logrus is in maintenance-mode.

One of the benefits of zap is that it avoids the reflection interface.

With regard to creating an interface in front of it, that is fine. However, I am not sure that is worth the effort. In my experience, it is more important to understand how the framework can be configured/plugged to send the log messages to different places.

[f0rmiga]

There's almost zero effort to wrap the logging framework and a lot of effort to replace a logging framework if such a wrap doesn't exist.

I'm fine going with zap.

[cgrindel]

Related to #26, #81, #94

[cgrindel]

Created a document to collect requirements from the various issues and centralize some of the research.