* If the user has already declined, we don't show that the other
  introducee has declined as well. The backend doesn't have that information, so
  this is compatible with the principle of showing what we know.
* If the user has already accepted or hasn't yet responded, we show the
  decline response in the private conversation with the introducer. If
  the user hasn't yet responded, we hide the accept/decline buttons
  in the introduction request message.

Messages an introducee receives in a `FINISHED` state are now being
ignored and deleted.

Closes #295

Will currently fail at runtime; requires a public key and a server onion.

* force decline when two of our own identities are introduced to each
  other
* throw away introduction requests to the same identity
  (impossible to trigger from UI)

Closes #284

(except refactoring of conversation item classes)

When devices' clocks are out of sync, it is possible that a response is
shown before the request. This commit makes sure that the timestamp of
responses is always later than the last message in the conversation.

Some wording could be misunderstood to thing introductions were
successful even though they were not. That has been clarified.

A new database transaction was created when getting contacts and local
transport properties. This has been changed to re-use the existing
transaction.

Also addresses minor issues found in review.

Show system notification for successful introductions

@color/briar_text_primary is used in a lot of places other than the settings screen - if we want to use grey text in the settings screen we'll need to find another way.

Also fixed some misspelled resource names and included the colours from the Briar palette in color.xml.

Includes code from https://github.com/consp1racy/android-support-preference
License: Apache License v2.0

This commit renames identicons to avatars in field names, and uses an ImageView
derivative to show the identicons, which should make implementing #214 easier.

Due to the nature of how Android app install/uninstall works without
root, this requires manual confirmation after a panic was triggered.

Closes #211

PanicKit does distinguish between two kinds of panic responses:

* default responses such as logging out which are non-destructive and
  do not require user interaction, so that the basics work without
  configuration
* destructive responses such as deleting user data. These require
  some sort of authentication to make sure they are not triggered
  by malicious apps

The second type of responses is implemented with this commit.

Authentication is done by comparing the package name
which is very weak. It requires the user to opt-in to
destructive responses and to configure from which app
to receive those (since there might be many different panic
trigger apps).

While possible to uninstall an app and install one with the same
package name afterwards, this always triggers notifications to
the user (if the attacker does not have root access).

Still that is no sufficient security for Briar's requirements,
so that TrustedIntents are used as well to make sure that the
app sending the destructive trigger is signed by a signing key
that we specified before. Currently, that is the one from the
GuardianProject and from IilabEngineering who does the Amnesty
International Panic App.

The responsibility of checking that the panic TRIGGER is
legitimate lies with the app responding to the trigger, so Briar
in this case. This commit checks whether the TRIGGER comes from
a trusted app before performing destructive actions,
but does perform the default action even when triggered from
untrusted apps.

Closes #210

This closes #204

Also removed some unused code from BaseActivity.

* removing screen border visible on small screens
* showing noticeable error message on wrong password input
* showing keyboard again after entering wrong password
* making lost password link easier to recognize as link
* renaming keyboard toggle method from 'hide' to 'toggle'

This now handles progress bar and empty view itself.
With this commit, it also scrolls down on layout changes like when
keyboard is opened.

Also fixed some IME action issues on Android 2.3.

It is a common pattern to have a list with an empty view and a progress bar.
This commit introduces a custom BriarRecyclerView and uses it for the
contact list.

No more manually hiding and showing empty views and progress bars is
necessary when using the new BriarRecyclerView instead of RecyclerView.

Please note that this conflicts with !44 at the moment and needs to be
implemented for !36 once merged.

Closes #198

The button hides itself when you scroll down the list of contacts
and shows again when you scroll up.

To properly color the button, the accent color has been defined.
It uses the same color as the action bar (primary color).
I leave it to a UX designer to adapt the color scheme.

Please note that the design support library was used.
It includes the app-compat library, so this has been removed
from the `build.gradle` file.

Closes #199