Exclude Insecure Devices | Find/Document the recommended way for bots to verify themselves

As part of #2700 devices which are insecure (not cross-signed by their owner) will be excluded from sending & receiving encrypted messages. This includes bots: if bot devices are not cross-signed, they wont be able to communicate any more.

We need to document options for bots to verify themselves; interactive verification via emojis is clearly not easy for bots to implement.

Some ideas:

* There used to be a `Manually verify with text` option on Element Web (removed in https://github.com/element-hq/element-web/pull/28588). Supposedly the user had to manually confirm the observed Ed25519 key matched the expected key; in practice everybody blindly smashed "Continue" so it wasn't the best UX, security wise.

We could maybe reintroduce something similar, possibly as a dev tool, slash command, or advanced option.

Bonus points if it forces the user to paste in the expected Ed25519 key rather than encouraging poor security practices. Doing so would obviously require the bot to display the Ed25519 key, but matrix-sdk-crypto does log the Ed25519 key on startup, so that shouldn't be a high bar. We could always expose some sort of `--please-insecurely-expose-me-to-a-mitm-attack` option if necessary.

Edit: this solution now tracked at #2751.

* Give the bot the recovery key (eg, via an OS environment variable), allowing it to fetch the cross-signing keys from 4S. This should be easy enough, but might require changes to bot implementations

* Create a commandline tool which will take arguments of username, password, device id, expected ed25519 key, recovery key. It logs in, downloads the device list; if the given device has the expected ed25519 key then it uses the recovery key to obtain the cross-signing keys and cross-signs the device.

* The bot exposes an alternative interface (say, an HTTPS server) which can be used to help it verify itself. See MSC3062 for a proposal here.

Review the context in #2700, the alternative tracked in #2751, and the MSC3062 proposal. Compare the listed bot-verification approaches, including recovery-key handling and the matrix-sdk-crypto Ed25519 key flow. Done means documenting a recommended approach, its security trade-offs, and any implementation constraints for bot authors.

Written by the indexing model from the issue text.