`log` usages complicates using as a library

[directionless]

Hi! In the vein of #175 I was playing with fscrypt as a library to get information about a directory. One thing I noticed, is a bunch of debugging oriented logging. To disable it, I ended up wrapping my calls to fscrypt with:

	origLog := log.Writer()
	defer func() {
		log.SetOutput(origLog)
	}()

But that feels a bit messy? I'm not sure if y'all have any thoughts about this, but I wanted to mention it as a small annoyance.

[josephlr]

Ughhhhhh, I hate that Go's builtin logging doesn't have proper FATAL/ERROR/WARNING/INFO/DEBUG leveled logging.

Maybe we could switch to a better framework, unfortunately there seem to be multiple.

[josephlr]

So the options are:

• Do nothing (users are then sad, but have a workaround)
• Remove all/most logging (makes debugging hard)
  • Could make debugging a flag, env variable, or build option, but that's messy
• Use https://github.com/sirupsen/logrus
• Use https://github.com/google/glog (aka Google3 logging)

[directionless]

It's the globals part that's so painful...

For what it's worth, I use github.com/go-kit/kit/log. The general pattern I have is that my New methods either take a logger, or I embed one in the context. Then all the library functions can call that, and the main routine can initialize it however it likes.

I'm curious about go.uber.org/zap, I see that in a couple of places.