[Reviewer: Andy] Rework the fake logger used in UTs

Mike, Andy,

Can you give this and https://github.com/Metaswitch/cpp-common/pull/120 a quick look and see if you agree with the direction I'm taking? This isn't quite finished and needs polishing and porting to the other cpp-common users, but I wanted to make sure I'm not doing anything fundamentally wrong.

I've broken FakeLogger up into:
* a PrintingTestLogger, with a static instance, PrintingTestLogger::DEFAULT. This has methods to change the logging level and noisiness, but by default it honours the NOISY environment variable
* a CapturingTestLogger, designed to be created when you have a test that needs to check a log file, just within the scope of that test. On construction, it sets the log level to maximum to avoid false negatives. On destruction, it hands control back to PrintingTestLogger::DEFAULT, which resets logging to the level of the NOISY environment variable. (I only realised it should do this in the destructor a bit before my battery died, so there are still some explicit calls to PrintingTestLogger::DEFAULT.take_over() dotted around).

The rules for creating them are much clearer:
* you never create a PrintingTestLogger because none of them can behave differently from the default
* you create a CapturingTestLogger on the stack inside any test functions that need it

Consequently I've:
* removed the per-test class FakeLogger member
* removed the static pointer to FakeLogger we had somewhere
* removed the calls to Log::setLoggingLevel(99) scattered through random constructors.
If they set _logger to NULL, what leaks? We create one logger on the heap and we delete it on destruction.

If someone creates their own Logger on the heap and sets Logger to that, AnalyticsLogger doesn't take ownership of the memory (and doesn't have a guarantee that it's heap-allocated anyway) - the caller has to keep track of it and free it.

I toyed with using std::shared_ptr for this stuff, but thought that would really be overkill. In a real program we create one Logger on startup and use it for general logging, and AnalyticsLogger uses the default logger and frees it. In UT we create one stdout logger statically and everything uses it - even AnalyticsLogger - except for when a stack-allocated CapturingTestLogger temporarily takes control (and AnalyticsLogger doesn't use that). I can't see that we're ever going to need any more than that, or to create so many loggers that we lose track of them.