Enable application side logging of hashicat runtime

[eikenb]

Add support for injecting a logger into the Watcher to support logging it's events.

Should allow for injecting our logger, go-hclog, but should attempt to be as generic as possible.

[eikenb]

For some context on why this was implemented the way it is, here is a snipped from a document I wrote up based on a bit of research I did on the current thoughts about enabling logging in libraries.

--

Discussions about a more featureful standard logging library.

https://github.com/golang/go/issues/13182
https://github.com/golang/go/issues/28412

The conclusion is to keep it simple but make it an interface. They discarded
the idea of adopting additional features, like log levels, as logging is to
varied to have one standard, complex interface.

Instead the decided convention that best enabled logging to plug into a library
is a callback. Callbacks allow you to handle logging, metrics or whatever you
need in relation to the events triggering them. This position is spelled out in
a golang-dev thread on standardizing logging.

https://groups.google.com/g/golang-dev/c/F3l9Iz1JX4g

Notably this paragraph.. ("our proposal" being a new log package proposal)

Note that we do not plan to submit our proposal to the Go project because we
now believe that a standard logging interface is the wrong approach for the
wider Go community. Instead we believe that widely shared libraries should
expose event data via a more richly typed callback API. This approach allows
applications to optionally handle the events as they need. Perhaps they log
(with their preferred logging implementation), or perhaps they do something
else. See, for example, how the golang.org/pkg/net/http/httptrace package
enables many more use cases than just logging. I briefly touched on this topic
starting at slide 47 of my presentation.

The httptrace package, used above as an example of what this might look like,
uses a large structure of callback functions. Things like "GotConn", called
when a successful connection is made, and DNSDone, called when DNS lookups
finish. It has 16 different callbacks for different cases.

This works but is clumsey and only extensible by adding more functions, but has
the upside of allowing the different callbacks to have different signatures.
I'd like to keep the benefits of a callback system, along with the ability to
have data releavent to the event (enabled by varied signatures), while having a
cleaner, more easily extensible API.