and stay in it when configuration changes

Closes #370

part of UI changes for #305

Methods for creating, adding and removing forums have been moved to the
`ForumManager`. In order to still handle removing forums properly, a
`RemoveForumHook` has been introduced.

Methods for sharing forums with all current and future contacts have
been removed along with the localGroup where this information was saved.

The `ShareForumActivity` now has the proper label.

The `SessionId` and the `ProtocolEngine` have been moved to the
`clients` package.

This addresses part of #322 and part of what has been discussed in #320.

This commit is a small change that replaces the custom UI elements in
the forum list with a Snackbar and an Toolbar menu.

Addresses one part (2b) of #305

This commit introduces an abstract `BaseContactListAdapter` which provides
most of the adapter logic. The original `ContactListAdapter` extends it to
show date and online status of the contacts.

The new `ContactChooserAdapter` which is used for introductions extends
the `ContactListAdapter` and adds logic for graying out contacts from
different identities than the currently used one.

A new `ContactSelectorAdapter` extends the `BaseContactListAdapter` and
allows to select multiple contacts. It offers a method to return a
collection of all selected `ContactId`s.

This commit also sneaks in an animation when the 'Share Forum' button
is clicked.

Closes #292

Removes all programatic calls that modify the layout and uses the XML
resource instead.

This also introduces constants for the GROUP_ID, FORUM_NAME and
MIN_TIMESTAMP as they were used for the two buttons.

Closes #313

* 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.

Closes #293

* 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.

The code made the assumption that a session state can be identified by
the unique session ID. However, when multiple identities from the same
device are involved, there are two sessions with the same ID running on
the device.

Hence, a second identifying criteria has to be used to uniquely identify
the correct session. Here, the ID of the group was chosen.
Unfortunately, the session state can not be cached easily anymore
leading to a small performance penalty when getting all messages for the
UI.

Show system notification for successful introductions