Thread safety changes

This pull request addresses the mentioned basic thread safety issues while keeping the API mostly the same. In particular I changed the following:
* **All methods documented as overridable** (`writeLogMsg`, `beginLogMsg`, `logMsgPart` and `finishLogMsg`) are **now `protected`**. They are the ones who no longer need to implement thread-safety themselves and never get called by user code. They are only called by library code that synchronizes with the Logger's mutex before calling them. When implementing your own loggers, remember to not accidentally make the overrides public.
* `stdlog` when set to `null` will swap the default logger back in.
* The unittesting symbols like `randomString()` no longer leak into user code.
* The function **`isLoggingActive` is now split into an compile time constant and a template** (`isLoggingActiveAt`) for a specific level. The return values are the same, but code & symbols for the functions are no longer emitted.
* **Compiler now warns about unimplemented Logger methods** (instead of ending with linker errors).
* **All methods except the ones documented as overridable have been made final.** This is to implement the thread-safety measures inside these other methods and be safe from later overrides that break them.

A word on Logger chaining: A special method for logging chains has been added to replace the now inaccessible `writeLogMsg()` with the name `forwardMsg()`. As public a method it will do the proper synchronization before calling `writeLogMsg()` internally and not check the `globalLogLevel` again.

Note: This pull request does not address the recursive logger call issue.
I previously replied to that in the conversation thread (https://github.com/burner/phobos/pull/2#issuecomment-56313203). There are several motivations for that modification:
* Final methods can get inlined by the compiler.
* Even if they don't, there is a small performance benefit from not going through the vftable of the Logger instance.
* Virtual methods should be used sparingly and documented as extension points. Making a final method virtual later is possible, but making a virtual method final is a breaking change, which became apparent when a method in std.zip that was not designed to be overridable, was changed to final and someone's code broke. To cite Walter from the "final by default" discussion: "The argument for final by default […] is a good one. Even Andrei agrees with it."
* As shown in FileLogger, bottom-up synchronization spread out over 3 methods is easy to get wrong. In this PR I followed the idea that thread-safety is easy when you lock all mutable state at the top most level. By making the public methods final and have them take the lock, the four protected, overridable methods are safely encapsulated.
* `log` and other methods of its kind encapsulate the basic behavior of a Logger as documented (checking its log level and the condition and calling the fault handler), which are customizable through `logLevel` and `faultHandler`, and pass their arguments as is into `beginLogMsg`, which can be overridden. They don't contain anything worth overriding in my opinion, and this change alone should not preclude any use cases.

See also commit https://github.com/mleise/phobos/commit/f757f2b951e3cebd8597e4eb71231857e0a42aa0 and the PR description https://github.com/burner/phobos/pull/2#issue-43313812