Often this isn't even needed since most contact removals are not of a PSTN
gateway.  Worst case they end up with an extra phone account in system, but if
we can't remove probably it's not there or owned by us anyway.

We already verified we are on a version that supports it.

Looks like merge error

And clear history into more options

* inversion:
  Don't jump straight in, since the conversation list is safe now
  Never show setup dialogs during onboarding
  Try to get list of commands for any domain jid
  Hide cancel button when onboarding
  When entering cheogram.com conversation while onboarding, go to register
  Hide menu and fab when onboarding
  Use the JID from the link
  Never show tabs in onboarding mode
  This doesn't even work, because we never treat cheogram.com as a stranger
  If onboarding and just cheogram.com conversation open, switch into command flow
  When starting command, wait for account to connect
  Switch to existing session when there is one, for incoming intent
  Start onboarding where we left off
  Fix NPE
  Fix NPE
  Allow cancel onboarding
  Inverted flow happy path
  If a command response indicates an XMPP URI, jump to that
  Make sure UI update happens even if the View was not attached when the iq came in

And don't switch unconditionally, since we want you to be able to start a new
flow from a link/button even if you still have the last page open from before.

Sort so that cancel comes before prev comes before everything else

Which may contain a resource

If they didn't cancel but rather chose an option which could not be completed
under inversion, start where we left off.

If this is just a register not part of inversion, archive the conversation when
they say "no thanks" so they get back to their regular first start experience.

If this is part of inversion, remove the onboarding account since they aren't
going to use it and set a flag so we know to redirect to magic create instead of
back to the welcome screen.  The flag also lets us know not to offer cheogram
again right after magic create like we normally would.  Then we can clear the
flag out and move on as usual.

When doing first-time signup, create an account on the onboarding server and
jump into register command at cheogram.  When that command is done, we expect it
will give us an OOB with xmmp:domain.tld?register which will jump us into magic
create flow for that server.  Once the new account is setup, if all we
previously had was an onboarding account we execute jidSwitch and delete the
onboarding account.

If anything goes wrong you are left with the onboarding account still tied to
cheogram and set up in the app as a "normal" account.

If the registration finishes without jumping you to a ?register URI you are left
with the onboarding account, but if you make an account then it will do the
switch after that (it tries the switch blindly, without checking if the current
backend supports it).

If you press "no thanks" you just get a spinner forever.

If this is part of completed or canceled then the existing logic will close out
the command run since we do not set responseElement to anything here.

Someone took ours somehow?

* 'color-resources' of git.sr.ht:~hdasch/cheogram-android:
  Fix ColorResourcesTableCreator creation exception.