Move matrix-sdk::encryption::backups to matrix-sdk-crypto so that it can be used by clients using that crate

[richvdh]

We have a useful module called matrix-sdk::encryption::backups (documentation, code) which is responsible for managing server-side key backup. It would be useful to move that module to matrix-sdk-crypto, so that it can be used by clients like Element Web which depend on that library (and currently have to duplicate the backup-management code).

[richvdh]

I looked briefly into what would be involved here. Some notes:

• Currently, it relies on the matrix-sdk Client to keep track of the "tasks" (kinda background processes) to download and upload key backups, and a couple of in-memory mutexes. We would need to find a new home for these. We could move them to a new BackupManager object in matrix-sdk-crypto which is initialised with an OlmMachine, and could be exposed through the bindings...

• ... but then we get into the question of handling the cross-process crypto store lock (or the equivalent on EAR and EiR). These are both handled by throwing away the OlmMachine and creating a new one. So I guess we would need a mechanism to replace the OlmMachine inside the BackupManager?

• We'd need to change the way we handle outgoing HTTP requests. Instead of calling Client::send, we would need to queue them up and return them from OlmMachine::get_outgoing_requests, which would also require a bunch of boilerplate in the bindings.

• There is also an object BackupClientState which is currently part of the Client but I think could move down to the BackupManager.

• We would need to fix the TODO in Recovery::update_state_after_backup_disabling and wire up a mechanism for the recovery system to subscribe to notifications that the backup has been removed. (We could probably have BackupManager relay the notification from the OlmMachine, so as to avoid dealing with the OlmMachine being replaced in too many places.)

My basic conclusion: there's quite a lot to do here, and much of it is made harder by the fact that OlmMachine is somewhat ephemeral. We should probably fix #2624 first.