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.
It would be really neat if the two `stdlog` functions could use atomic operations too (the setter could maybe use `cas`), but they're probably not called often enough that it makes any difference.