Uses phone location and libphonenumber to normalize.

Rather than starting right at dialling, which seemed to cause sometimes delays
in the in call screen appearing and also a different behaviour when a post dial
string was present, passing through all the states with some time in between
seems to result in a more stable and consistent UX with no change to functionality.

* more-tags:
  Default dynamic tags to on
  Display phone number type/label as a tag where relevant
  Show dynamic tag "Android" when item is in Android contacts only

* dialler-integration-permissions:
  Ask user for microphone permission from dialler integration

* gateway-icon:
  Show gateway avatar on in call screen

We can't ask them for it directly.  The library I am using here will first check
if the permission is already granted.  If so onPermissionGranted will fire and
we will start the call.  If not, the Connection will be created in a dialling
state and a notification will appear saying that the app needs additional
permissions.

Once the user taps the notification they will then be asked to allow microphone
access.  If they say yes, the call will proceed.  If they deny, the call will terminate.

* pstn-gateway-can-call:
  PSTN gateways contacts can do voice calls

* sync-tel-contacts:
  Sync system contacts by phone number

* dialer-integration-2:
  Mostly rewrite dialler integration
  Much prettier calling account

Using the same logic as Quicksy, but not submitting to an API just assume that
tel@pstn-or-sms-gateway is a valid Jabber ID.

Does not add to roster or reveal presence or send anything to a server, just
affects local UI.

If we are in a fallback situation (no presence) then always allow AUDIO if
domain matches a known PSTN gateway.

Doing it properly this time. No Intent, no popping a second activity, just
instrument the call into the Android UI.

This turned out to be a bit easier than expected.  The ConnectionService does
indeed run inside our app process everywhere it matters, so we can reuse the
machinery from elsewhere to get a reference to XmppConnectionService.  Asking
JingleConnectionManager to send propose is enough to kick off all audio, etc.

Put in a guard that the JingleConnectionManager expects so that we won't try to
start a call if isBusy is true (that is, if another call is in progress), and
just return a failed connection BUSY in that case.

Added a flag to XmppConnectionService that we set when using the dialler
integration so it will temporarily ignore phone call state and not hang itself
up.

The app still shows a separate call notification, so you see two in-call
notifications.  You can also go into the app during the call and manually pull
up the call UI there.  If you do anything in either call UI it will work and
sync state, so that's not dangerous just perhaps odd.

Kept the connection address as a tel: for contact integration in the call
history, but use our normalized version now instead of whatever we got raw from
the system.

Add support for post-dial DTMF including 2-second pause with comma and
manual-length user-intervention pause with semicolon.  Dial with 100ms break
between tones.  Doing no break at all mostly works in practise, but not for two
identical tones in a row, this seems to be enough in my tests.

When using a post-dial string from contacts the UI shows more/different state
than it should and at least in my emulator plays a different ringback tone for
one ring before switching.  Very odd, as though it's partially ignoring our
Connection object's settings.

Audio routing has not been tested yet (for speakerphone, bluetooth, etc).

Register the service avatar, perpy background for call UI, and split the User's
JID into the headline with the service JID (eg "cheogram.com") only shown in
short description.

To be more user friendly

* contact-links:
  Show contact name in an xmpp: link

When rendering an xmpp: link, show not the raw URI, but the contact name
(if there is one) or JID (if there is not).

* phoneaccount:
  any means none means false (ie there exist) unless upstream reports a reason
  Small fix to address cheogram adding "+1" when making calls from the default dialer. Now only adds "+1" or "+" when necessary.
  First version of dialer integration
  Revert "Intercept DIAL and CALL to tel: and rewrite to cheogram"

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.