When a contact comes online, we check if it is a gateway/pstn.  If so, we
register a new PhoneAccount with the OS for the account+gateway pair.

When the roster is being saved after any change, we check for any items that
have been removed and remove any associated PhoneAccount registration.

To activate a PhoneAccount, a user navigates to Phone App > Settings > Calls >
Calling Accounts.

When a call is placed from the Phone app using one of our PhoneAccount, the
ConnectionService is called by the OS.  Its job is to place the call and keep
the OS calling UI up to date via a returned Connection subclass.  Calling in
Conversations is currently rather tied to the UI, so rather than seperate it out
for this prototype, I launch the Intent to bring up the UI for the desired call.
This should do jabber:iq:gateway on the gateway and possibly other fallbacks,
but for this prototype it just strips any non-digit and prepend +1 if not
present, appending @gateway.tld for the associated gateway.

We don't actually tell the OS UI when the call is active, because if we do it
steals focus and puts the whole system in "in a call" mode, which causes
Conversations to deactivate its UI.  This is something to explore more if we
want to use the OS in-call UI completely.  We also haven't wired up the OS UI
for DTMF since it never shows if the call is never active.

We *do* tell the OS UI when the call is over, so it can clean up and close the
other window.  This means that after you hang up in Conversations, you are taken
back to the OS UI showing "call ended" for a few moments.  It also means that if
an outgoing call fails you will see the OS UI for a few moments before being
returned to Conversations to see the normal call failure screen.  This is
perhaps the biggest wart of the current prototype.

As an alternative, we could just pretend the call immediately failed and have
the OS UI close itself before the Conversations UI ever comes up.  This
basically causes a indeterminately-long "flash" of the OS UI, possibly long
enough to see it say "call ended" before we get the Conversations UI which then
works after that.  I thought that was more confusing that what I'm doing now,
but maybe others disagree.

Finally, outbound calls placed from the Phone app do show in the Phone app call
log.  Other calls started from Conversations or inbound calls could show there
with a full integration, but that's not part of this work.

This reverts commit 227dd8d2bcbb86599b22483bc56972aab66d7890.

* singpolyma/dtmf: (145 commits)
  Detect a video call in a consistent way
  Use a boolean for this state
  Switch onClicks to use DataBinding
  Polyfill to allow use on Android 21
  RtpSessionActivity: Fix NPE from using incorrect view id
  Changed dialpad icon to something more recognizable.
  Cleaned up DTMF code and click handling.
  WIP - dialpad and dtmf sending
  flush stanzas in batches
  code clean up in TagWriter
  Fix #4249.
  Clarify build instructions.
  allow verification of own omemo keys via uri
  bump dependencies
  version bump to 2.10.3-beta
  fix precondition for timeout handling
  bump agp version
  pulled translations from transifex
  add Samsung S4 to hardware aec blacklist
  add additional logging to image compression
  ...

Included SVG of icon in assets.

Min API version change was required for user interface lambdas.

This is used when something goes wrong with a MUC, e.g. a connection
error made the MUC kick you out. In this case you generally want to try
to rejoin.

fixes #4267

This is fairly unlikely to happen in practice

otherwise setLocalDescription and the arrival of first candidates might race
the rtpContentDescription being set

turns out we don’t need it and a better way is for RtpConnection to keep track of *all*
states in the current generation

using the parameter-free form of setLocalDescription() solves some potential race conditions
that can occur - especially once we introduce restartIce()