Consider UIA flow design on deactivation dialog

When doing UIA the intent of the request can't be changed per the spec, which means the user can't suddenly decide that they want to erase themselves without abandoning their current auth attempt. However, riot relies on a previous bug in Synapse where we could change the parameters in the middle of the flow.

We hit the server for the auth flows to see what form of password entry we need (SSO, actual password, etc) and show that alongside a checkbox to optionally erase their data. This erasure checkbox is the thing that can change the parameters of the request, which the spec doesn't like (and neither does Synapse, now).

The workaround is for us to start a new session once the user commits to deactivating their account (starting the auth flow), though this is hard to do with SSO and similar flows. For the workaround, we hope that people won't click a checkbox after they've started auth - something they couldn't do for password auth anyways. This workaround raises a problem with the server's behaviour though.

The server only has to honour the flow the client is using while the session ID is active (assigned during the initial request). This means that when we start a new session the user could get different flows to complete all of a sudden (rendering the password previously entered potentially useless). The server also has an opportunity to deny the existence of a session ID, which we historically have not handled.

One cheap workaround is to have the erase checkbox and the auth steps on different screens (like a 'next' button before you can enter a password). This feels a bit like a wizard though, which historically we've been against for smaller actions (longer actions like cross-signing setup appear to be good fits).

This might be a fun exercise in what to do about UIA more generally, as it's complicated and doesn't fit our current designs. We could figure out what design works best for us, write an MSC or two, and try and get that through or potentially just design a complicated system which matches the spec's behaviour.