Crypto: Support recognising a clearText vs a decrypted to-device event

[BillCarsonFr]

Draft: Depends on a new wasm-bindings version matrix-org/matrix-sdk-crypto-wasm#226

Notes for reviewer:
Since the integration of the rust-sdk it was not possible to make the difference between a succesfully decrypted toDevice event and a clearText toDevice. With the new bindings it is now possible.

This PR integrates this change. The existing MatrixEvent end-points like isEncrypted(), getClearContent(), isDecryptionFailure are now expected to work properly for to-device events.

As for now the SDK is not returning and EncryptionInfo or OlmError, so some of other MatrixEvent will not work fully (getSenderKey(), decryptionFailureReason()).

Not sure what is really needed on all the existing code for MatrixEvent, or what could be removed (like all the deprecated DecryptionFailureCodes, the claimedEd25519Key, etc.., and a lots of things are megolm specific)
Maybe a dedicated MatrixToDevice event?

Checklist

• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• Sign-off given on the changes (see CONTRIBUTING.md).

[richvdh]

My initial thought on this: we're tying ourselves into painful knots by attempting to map processed to-device events into MatrixEvents. Most of MatrixEvent is inappropriate for to-device messages.

Could we instead:

• Define a new interface for incoming to-device events (ReceivedToDeviceEvent ?), and have preprocessToDeviceMessages return an instance of that interface.
• Deprecate the ClientEvent.ToDeviceEvent callback, but for now, keep it working by continuing to map them onto a MatrixEvent which just wraps the (decrypted) content
• Define a new type of ClientEvent whose payload is ReceivedToDeviceEvent and emit that as well.
• Where we care about the crypto properties of the incoming to-device event, switch over to the new ClientEvent.

[richvdh]

Also: I factored out some of the duplication between the two sync implementations in #4863. It would be good to land that first.