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` can no longer be read out** since we cannot guarantee the returned pointer will still be the `stdlog` when we call a method on it. *(For user code that needs to work with `stdlog` directly we could add a sort of `stdlogApply` function that takes a delegate with the code to execute in the context of `stdlog`. `stdlogApply` would lock the global mutex before executing said delegate.)*
* `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.
Couldn't this use an atomic read instead? Locking seems overkill