Make it possible for a Connection to provide (cached) data without becoming online

[Kaffeine]

Introductory

From the specification:
A Connection object in Telepathy represents an active (or activatable) protocol session. Depending on what features are supported by the protocol, a given connection will implement more interfaces than just Connection. The interfaces supported by a given connection can be retrieved using the Interfaces property once the connection is in the CONNECTED state.

In other words: Telepathy says that a CONNECTED Connection is needed to work with messages, contacts, rooms, and almost anything more than account credentials.
Probably the design and the statement were reasonable at the time of declaration, but now we have issues with modern IM features. For instance:

• Message Read Status — a user can read a message in offline and it is too hard for an upper layer (e.g. Client) to store the actual read status map and bi-directionally sync it on the account become online.
• Message History — in certain cases protocol details are needed to properly store, restore, delete, and sync_deleted messages. Plug "Server-Side History" feature and "an abstract service-agnostic logger" will become a virtually undoable complex nightmare.

Further key points:

• we can't break compatibility with the existing clients and services
• we can't rename Connection to something not that tied to connection

Proposed compromise solution

The idea is to reuse the existing code as much as possible. Right now we have Connection API available only after the state changed to Connected. Okay, let's add some Connection or ConnectionManager Interface.WarmUp to make the CM construct a Connection object without asking the connection to connect. See #24 for details.

Alternative solutions

New type of object in ConnectionManager's

We can add some kind of "AccountStorage" objects (see the spec of existing AccountStorage interface).

There is RequestConnection (s: Protocol, a{sv}: Parameters) → s: Bus_Name, o: Object_Path method in ConnectionManager API. We can add some RequestStorage (s: Protocol, a{sv}: Parameters) → s: Bus_Name, o: Object_Path that constructs AccountStorage object. The object has to expose messages, contacts, chats, calls history, and almost everything from the current Connection API. It means a lot of duplication in the specification and bindings code.

We already have too big codebase so this approach considered as "not worth it".