Decouple message queues from actors

[ForNeVeR]

This task is a prerequisite for #17.

Currently our Telegram and XMPP actors are sort of message queues themselves, and that creates troubles:

1. IM connection management is a complex task, and from my research in Make sure the client properly reconnects to both Telegram and XMPP after network outage #17 we can suppose that it doesn't couple with actor lifecycle too well (it also echoes the same problems we had in horta-hell, do you remember the old days folks?)
2. Sometimes connection could be in a bad state, but actor doesn't know about it yet, so it has no chance to even put the message aside for a while; some messages are doomed in the current architecture
3. Actor lifecycle management is not a bag of honey itself: if actor tries to manage the connection then it is asking for trouble

So, I've decided to move the IM to external entities. The architecture will be the following:

1. We'll have IM actors. There're just endpoints for the actor system and own no resources. Each actor sends messages to a corresponding IM queue and receives the messages from the IM.
2. We'll have IM entities. These consist of:
   • a never-ending reconnecting loop in case of any errors
   • a neven-ending message loop that awaits messages from the server, and sends them to a corresponding actor
   • an IM message queue: a queue (maybe even persistent in future, see Message enforcement architecture #24) that stores the outgoing messages; IM should take the messages out of it and try to send them (and retry if necessary whenever any error occurs)

This allows the messages to be reliably sent to other end of the pipeline without losing them, actors to be successfully reborn in case of whatever errors cause them to die/recycle, and the IMs to function independently of actor lifecycle.