Add a logging trait which can also log exceptions

Thanks for the patch, great job!
However, while this correctly implements the second part of the proposal, it's missing the first part – i.e., implementing dependency injection in this trait and replacing all our current code for logger dependency injection with that (except for the necessary code in the create(), of course).
(This also means that logException() can't be static.)

Here is my take on this, please review!

I've refrained from including a call to the setter in the various create() methods, though. I have been doing this religiously till now, and also argued for it over in #2311039: Implement proper dependency injection where possible, but in the end I don't really see why we need it. I thought it's the "clean" way to do it, but in the end everyone does it differently anyways, and I can't really see any benefit in having it there.
After all, in tests we can still just call setLogger() if we need to – why would we need the "detour" via create() for that? We usually don't even use that in tests.
Also, looking at some of our classes closely, if we really would want to keep to the rule of setting all the dependencies in create(), it would significantly bloat up some of them – for no apparent gain, at least to me.

Does anyone have any arguments why we should still include that (or why some other way of DI is better)?
If not, I guess we could even talk about removing such setter calls from all classes where we currently have them, for consistency's sake – maybe #2311039: Implement proper dependency injection where possible would be the place for that.

One question I then have, though, is why we have create() methods in the Core framework?
I guess just for the DI variant where you pass all dependencies in the constructor – but I can't really see the appeal of that, either.

OK, thanks for your input on this!
Also thanks for reviewing – committed.