Rework debug logging #125

Added new function, OutputLogMessageF, which contains most of the functionality of OutputDebugStringF.

OutputLogMessageF has two additional parameters over OutputDebugStringF: an enum indicating the context of the message, and an enum indicating the verbosity level.

The existing OutputDebugStringF forwards itself to OutputLogMessageF, passing enum values indicating a log context "Legacy", and verbosity "Debug".

Additional functions have been added to support the feature. These functions:

• add and parse command-line options -logcontexts and -loglevel to set the logging context and log verbosity (respectively)
• change logging context and verbosity programattically

Several of the calls to OutputDebugStringF in main.cpp (which are hidden by the macro 'printf') have been changed to use OutputLogMessageF, to demonstrate how the new logging system works. I have not changed all occurrences (there are still 90 occurrences in main.cpp, and I haven't even touched most of the other files).

The change has been designed in such a way that migration to the OutputLogMessageF can take place as developers work on various sections of the code. The existing 'printf' calls still work, and can be viewed by using the command line options -loglevel=debug -logcontexts=legacy.

My first reaction: this violates the KISS principle. My second reaction: if the consensus is that more complicated logging is needed, then why not use boost::log?

I forgot to write my motivation for the patch. I wrote it because I got tired of having to sift through hundreds of "IRC got xxx" messages while I was trying to debug some other changes I was making. Plus I was concerned about the size of the debug.log file - after running for only 12 hours, the file was hundreds of megabytes. The file only gets truncated on startup, and then only if you specify the -debug flag - which increases the log activity.

I haven't looked at boost::log, but how easy is it to incorporate into the existing code? One of the big advantages (IMO) of this patch is the fact that it fits into the existing code, which makes it less of a pain to migrate to the new logging system.

This seems to match logging systems from other complex software projects. The sheer number of messages in a complex system begs for something like what jhyslop has submitted.

BIND uses logging channels, giving you the ability to mask-in and mask-out certain types of messages. syslog has LOG_{ERR, WARNING, INFO, DEBUG}. Linux kernel network drivers have a facility (NETIF_MSG_xxx) which permits enabling or disabling of high volume per-packet messages, enabling or disabling of PHY-related messages ("link up!", "link down!"), enabling or disabling of driver probe detail messages, etc.

I think it would be useful to selectively enable or disable (a) bitcoin's per-packet logging, (b) P2P logging in general, (c) RPC logging in general.