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

and indicate which transports are currently available.
The icons have been chosen from the official material icons and might be
replaced later with icons that better represent the given transport.

Please note that I used vector drawables which will be automatically
converted at build time to raster graphics.

Closes #96

Provides a checkbox in the settings view, as well as an event handler to
disable/enable the tor network if the device is not on using the wifi
connection.

Refactors network-enabling code to a separate function. This function
is ran after the network state changes, or the settings change and
will update the status accordingly.

and fix message divider background for lower API levels.

Closes #97

UI was transferred into XML files
and lots of redundant code was deleted such as the custom CodeEntryView.

Closes #33

Users were confused by the process of adding a contact for the first time.
This change adds additional explanation and a picture of what is going on.

It also moves part of the UI into XML files.

Closes #87

The text of the startup failure notification is unhelpful due to lack of
space. Touching the notification now launches an activity that gives details
of the problem and what can be done about it.

Closes #38

We don't need two separate executors for long-running IO threads.