std.experimental.logger formal review round 3

[Martin Nowak via Digitalmars-d]

On 09/28/2014 02:24 PM, Dicebot wrote:
> Important changes since last review:
> - new approach for compile-time log level filtering

What's new here? It still relies on version identifiers to do so.
As I said in some earlier review, I think it's a bad idea for a library 
to rely on version identifiers that are defined in client code.
I will only work for templated code and makes it much harder for build 
tools. In a way it's the equivalent of
     #define LOG_LEVEL 2
     #include <logger.h>

I even proposed an alternative that uses type tags instead.
http://dpaste.dzfl.pl/95fb6a4e086d

> Usual process : 2 weeks for checking out if there are any critical
> issues that are likely to prevent successful voting, write a comment if
> you need more time for review, focus on API issues.

- Documentation is out of sync.
- ArrayLogger seems to do about the same as MultiLogger
- Why do loggers have to be classes?
   - Define a concept (isLogger template) with the requirements.
   - Add a Logger interface and a loggerObject to wrap structures when 
polymorphic loggers are needed.