The new activity shows who you are sharing a forum with and who shares a
forum with you. It is accessible from the overflow menu when in a forum.

Closes #398

Closes #391

The code for creating forums in ForumManager was used by
ForumSharingManager and also needed by InviteeEngine.
This extracts it into its own class.

Closes #375

for introducer when both introducees have been deleted.

Closes #372

It was possible that a malicious introducer sends new request with the
same session ID that was used previously and thus causing introducees to
have multiple states for the same session ID.
This commits prevents that from happening and adds an integration test
for that scenario.

Also if an introducee removes an introducer, all past session states
will be deleted from the database. For this, a test was added as well.

Closes #371
Closes #372

This adds integration tests for these cases:
* normal invitation session where invitee accepts
* normal invitation session where invitee declines
* session where invitee leaves again after she joined
* session where sharer leaves after invitee has joined
* session where sharer leaves before invitee can respond
* sharer reuses the session ID of the previous session
* after accepting the invitation, the invitee invites the sharer to the same forum
* after session contacts delete each other and session states get cleaned up

Closes #339

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.

* 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

* normal session where both introducees accept
* normal session where the first introducee declines
* normal session where the second introducee declines
* one session where a contact is introduced to herself
* one session where two identities of the same contact
  are introduced to each other

This introduces a new IntroductionAbortedEvent to signal when the
protocol was aborted. It is not yet used in the UI.

It closes #276