Add logging to MultiplatformSettingsStorage

[zsmb13]

Breaks the dependency cycle between the storage class and the logger so that the storage implementation can also contribute to logs.

Fixes #544

[kropp]

We may lose some messages here, both between forEach and clear, and between clear and setting delegate.
If adding a lock is undesirable, I'd suggest at least draining the buffer again after setting the delegate.
Another improvement would be to remember the last dumped message, cleaning the buffer only until that point, and again re-dumping the rest after a delegate is assigned.

[zsmb13]

I wanted to avoid a lock on the happy path of logging into a delegate that's already set.

But I now added locking for working with the buffer now. Any of those interactions should only happen during app launch and never past that.

[kropp]

I cannot get rid of the feeling, that we can resolve settings <-> logging dependency in some other way, without overcomplicating logging.

[zsmb13]

@kropp I'd love to have a cleaner solution as well, but I can't think of anything obviously better.

Some alternatives that I see would be:

• Reading just the debugLogging flag from storage by direct access and with no logging, going through a different interface than MultiplatformSettingsStorage, before we run storage-related migrations or anything like that.
• Have a proxy like we have now with BufferedDelegatingLogger, with a different implementation: we can make it create a new coroutine for each log call which will each suspend while the delegate is unavailable, and then continue and log once the delegate is set.
• Skip logging until we read the flags from storage and know what to do about logging - but this would lose important logs like the ones about storage migrations when we want to debug that.