Implementation of a persistent event queue

[brototyp]

This is for the most of it a copy of PR #377.

[bobunmeng]

This looks more sophisticated and it doesn't break the previous flow. I would go with this with no problem.
What I thought of previously was that a user doesn't have to bother creating their own queue if they want to persist their events. An argument "true" or "false" would do and we would do the rest of work from that.

[brototyp]

What I thought of previously was that a user doesn't have to bother creating their own queue if they want to persist their events. An argument "true" or "false" would do and we would do the rest of work from that.

That's a legit point. I think there is a bit of tweaking we can do with this implementation to make the usage easier. The think I really like with this implementation that it is very customizable. A user of the SDK would be able to implement yet another queue that fits their very special need, e.g. encrypt and persist it, or persist it in a database or so.

Maybe the persisted: Bool parameter could be in a convenience initializer. This way we could have the best of both worlds. At the same time: Maybe the persisted queue should become the default queue. If it is reliable, I think it might be worth the tradeoff (reduced performance but no (or much less) event loss).