Example change to allow bridging to other log systems

Example of a slightly modified logging setup which would then allow bridging to other logging systems, as I mentioned in the comments to #1926 . The code is probably not in the the best files, but it should serve to show what I had in mind, so you can move things to more appropriate places (RKLog? RKLogInitializer?) later on if you want to use it (or something like it).

First, I define a protocol (RKLogging) which bridges can implement.  There is a global variable storing the current Class for the actual logger.   There is a implementation of an RKNSLogLogger which logs via NSLog(), the same format as the current code, and which installs itself as the default logging class if not externally set.

RestKit 0.10.x did something like this, except hardcoded the class name instead of having a settable Class.  Even that was enough, since external code could do method swizzling to redirect the implementation to somewhere more wanted.  But the Class variable makes it more obvious, and easier to install a separate bridge class.  RestKit 0.20.x changed to a direct NSLog call meaning one needed to modify RestKit source to get something more dynamic.

This way, the bridge classes do not necessarily need to be compiled in RestKit -- they could be written externally and set at runtime, even for folks using a binary distribution of RestKit.  But, you could also do conditional header checks to a) provide some bridges if the log system exists in the local compile environment, and b) make some different log bridges the default.

I added an implementation of a CocoaLumberjack bridge which fits in this scheme.  It just forwards the values to the DDLog class method, translating levels.   It also adds implementations of DDRegisteredLoggers for each RKLog log component, so those classes show up in CocoaLumberjack's list of runtime-settable log levels.  I have not really tested this bridge, though a similar setup works in my real app.

Feel free to use this as a starting point for something else, or massage a little bit and use it, or completely ignore it :-)

Yeah, that would be a good idea.   However all of the code would still need direct access to the variable since it's part of the core logging macro itself, unless there is also an accessor function.  But having the setter function would mean the global variable can be documented as hands-off.