port to new soledad async api

**Not ready to merge, missing changes in leap.mail and maybe other to be compatible with the new API**

It needs to synchronize the merge with the soledad async API and the upgrades in leap.mail.
Let's develop a bit on this topic because I think `delete_key()` gives us a good use case example.

Suppose a user only wants to delete a key and nothing else. She does `d = delete_key()` and now she has a Deferred in her hands whose callbacks (including the actual deletion of the key) will be executed at some unknown point in the future. Suppose that in this case, the user just wants the key deleted and will add no callbacks to the deferred.

If I understand your point about the point of view of the user, you want the user to know that: "If you add a callback to the Deferred you now have in your hands, your callback will be fired after the key has been deleted".

On the other hand, the deferred that she has in her hands represents the asynchronous key deletion procedure, and the actual deletion callbacks (contained in that deferred) will be called at some unknown point in time. Also, if no callback is added by the user, the key will only be deleted and there will be nothing to be fired when the key is deleted.

So what I don't like about the idea of saying that the deferred will be fired when the key is deleted is that what actually happens is that when the deferred is fired, it will delete the keys, and then if there's any callback added by the user, then that callback will receive whatever the last deletion callback returns (in this case, it will return the new revision of the deleted documnt, as returned by `leap.soledad.client.Soledad.delete_doc()`.

A proposal that might address both your concern and mine would be:

    :return: A Deferred which, when fired, will delete the key. If you add a callback to it, your callback
        will be executed after the key has been deleted and will be handed the revision of the deleted
        document as a parameter.

A shorter version that might also address the question:

    :return: A Deferred which, when fired, will delete the key and pass the revision of the deleted
        document as a parameter to a callback you might add to it.

What do you think? This proposal is a bit longer but I think it explains what is happening and also documents when the user's callback will be executed and what parameter it will be given.

More ideas? :-)