Revamp discovery

[iinuwa]

This shifts the responsibility of starting discovery on each "interface" (hybrid, USB, NFC, etc.) to the frontend rather than the backend. This way, the backend only needs to signal that they're ready for the credential, and the frontend listens on all the interfaces it can.

This means that the backend only needs to:

• read and display the initial list of credential sources that must be clicked to be used (e.g. linked devices or credentials from password manager autofill)
• display the hybrid QR code as soon as HybridStarted is received
• Listen for an event that signals that an actual device has been selected by the user (HybridConnecting/HybridConnected, NfcConnected, UsbConnected), then switch to the UI relevant for that type of authenticator.

The UI could still show buttons to allow the user to make an explicit choice, e.g., if the backend decides to show the hybrid QR code as the primary screen for starting the flow, they can still show the "Use security key" button at the bottom as a secondary option. That would just be an aid to the user's understanding; it wouldn't affect the actual discovery.

Some design questions:

• Should we get rid of the UserInteracted::DiscoveryRequested (from backend -> frontend)? Once Use standard portal backend Request interface for cancellation #164 lands, we won't need this, as the frontend would be managing that interaction. It might be useful to keep, in case a backend wants to defer the blinky lights on the USB authenticators while it does an initial welcome intro screen, but I'm not sure if that's worth the extra latency.
• Should we move HybridStarted data into Initialize options instead of sending a separate event? The backend will essentially need it right away, so they might just wait until it's sent.
• Should we have a single "Connected" event with a transport attached?
• Is there a way we can make it easier for backends to know which events constitute a device selection, or is it clear enough?