Early review of std.logger

[Sean Kelly]

It's weird that LogManager.defaultLogger exists as a read-only 
property, and if I want to change it I have to use the global 
static "log" variable.

I think this was mentioned elsewhere, but is the global logger 
thread-local, shared, or __gshared?  Or is this something we can 
control?  I can see maybe wanting to have a separate logger per 
thread in some cases, for example.

I kind of wanted channels per Boost::Log, but simply creating 
multiple loggers that I can reference by name seems reasonable.  
Channels add a ton of complexity anyway.

We really need timestamps, and the timestamp format should be 
configurable.  One thing I like about Boost::Log is that I can 
statically specify the format of log lines.  This would be 
particularly useful when trying to integrate a D app into a setup 
that already expects a particular log line format.

This is an implementation detail, but I imagine the buffer these 
lines are written into is a static buffer that grows as needed 
and is just reused for each log line written?  I understand why a 
custom logger would receive only the generated log string, but if 
this is allocating unnecessarily in the background it could be a 
problem.  Maybe we could get some way to specify the initial size 
of this internal buffer as well, or limit the total buffer size 
to some value?  In some cases, you don't want to log more than N 
bytes per entry even if it means truncating the message.

Formatted logging should be the default.  I almost never want to 
just long a string with no parameters.

I'm not entirely happy with the conditional just sitting in the 
parameter list.  Maybe if the command were "logIf" instead of 
just "log" or there were some way to mark up the conditional in 
code as that it determines whether the log line is written...  I 
think this goes with my general aversion to using magic numbers 
as function parameters.  I either like the function call to read 
line a sentence or if that isn't reasonable, for there to be some 
way to indicate what a particular parameter is for.

For what it's worth, I think the conditional is a reasonable 
substitute for not having the LogLevel be a bitmask.

For the rest, I think the current API is sufficient to make most 
use cases work.  I might sometimes create a proxy logger than 
fans out to multiple discrete loggers underneath, for example.  
But that seems straightforward.