Explicit key verification signaling

This is a continuation of the discussion on https://github.com/matrix-org/matrix-doc/pull/1544

The need arose for explicit signaling so that each client knows what verification method is being presented, and to be able to switch between them. QR code verification would need modification to reciprocate in a separate package from "start".

Sorus idea would be to allow sending multiple start's. Each new start re-starts / switches to that verification method.
To be able to deduplicate correctly which start to use, the package would receive an integer counter. If it is absent or malformed (not an int) the counter is to be interpreted as 0. Each client is only allowed to send the same counter once, meaning we can have a maximum of two same counters (both clients)

The start with the highest counter is used. If there are multiple, then the one with the lexographically smaller mxid is used. if they match, then lexographically smaller device ID (same as in matrix-org/matrix-spec-proposals#2366 ) The difference to matrix-org/matrix-spec-proposals#2366 is, that the method picked can be different, and the start can be sent after other packages have been exchanged already, but not after an error or a done. This way clients can still switch to a different method after verification is initialized.

Of course there are other ways to model this, this is just one suggestion.

Clients could still present multiple verification methods on-screen (e.g. qr + nfc) and listen to them. If a different method is used than is `start`ed it could just immidiately send a new start for that one. e.g. client 1 sends a start for nfc, but listens both for nfc and displays a qr code. client 2 then scans the qr code, sends a start for qr code, and then sends the reciprocate.

Start by reading the discussion in matrix-org/matrix-doc#1544 and the related matrix-org/matrix-spec-proposals#2366 referenced in the issue. Compare the proposed counter, ordering, switching, and reciprocation rules with the existing verification flow. Done means an agreed, unambiguous protocol design rather than one of several competing suggestions.

Written by the indexing model from the issue text.