Provide Logger interface to use non-std loggers

[artek-koltun]

What

Provides an ability to use non standard loggers. *log.Logger is too limited and providing an interface instead of that concrete type makes integration with any other loggers much easier.

Impact

• Are your changes backward compatible? Yes. A compile time test is provided to make sure that the new interface is compatible with *log.Logger

• Have you included documentation, or updated existing documentation? Comment to the interface was added.

• Do errors and log messages provide enough context? Additioanl logs are not required...

[PaulSonOfLars]

Hi, thank you for your contribution! This is a really interesting PR, because its something that I've thought and lamented about for a while. In fact, I'm eagerly awaiting go 1.21 for the structured logging functionality!

The reason I opted to go for the standard library logger here (until 1.21 turns up) is to try and avoid people having to jump hoops to set up logging. Speaking from experience, it can be frustrating having to juggle existing logging implementations to fit each library thats being used. Ultimately, it leads to to confusion of "Hey, how can I use <zap/logrus/etc> with this, and this other library, and this third one".

Instead, sticking to the stdlib logger allows users to use the many preexisting methods to convert their custom logger to a stdlib logger - or even just to create a new stdlib logger, with a custom io.Writer!

Eg:

// zap exposes a method for this already
stdLibLog := zap.NewStdLogAt(zapLogger, zap.InfoLevel)

// logrus provides you with the underlying writer
w := logrusLogger.Writer()
defer w.Close()
// Log package can write to any io.Writer
stdLibLog = log.New(w, "", 0)

What do you think, does that make sense? or at least, do you agree that it makes sense to wait for go 1.21's improved logging?