Consider changing how we handle logging

[theodab]

trafficstars

Right now we use glog for logging. It is a stable library, easy to use, and extensible. The problem is that an app can't change our logging without also using glog. The app doesn't need to use glog for all their logging, but they will need to link against glog to be able to change how we print logs. To make matters worse, we link against glog statically, so we need to export the glog symbols and the app needs to use that version, they can't use their own version or it won't affect us.

Having us export the symbols (which we technically do now) is probably not a good idea since it makes glog part of our ABI, so we can't upgrade glog unless it is either ABI compatible or a major version number.

We could link against glog dynamically, which would make it more clear for the app. It also puts the app in charge of handling the glog dependency. Unlike FFmpeg, we don't need to worry about security concerns about loading glog dynamically since the only thing we give glog is stuff we are printing to the console anyway.

One alternative would be to write our own log abstraction. This could be implemented by the app to provide their own logging system easily. We would by default use glog internally and just hide it so the app doesn't need to worry about it.

We should look at other popular C++ libraries to see how they handle logging. FFmpeg uses a custom log callback, which would be similar to how I suggested above.