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.

This Introduction BSP Client uses its own group to communicate with
existing contacts. It uses four types of messages to facilitate
introductions: the introduction, the response, the ack and the abort.

The protocol logic is encapsulated in two protocol engines, one for the
introducer and one for the introducee. The introduction client keeps the
local state for each engine, hands messages over to the engines and
processes the result and state changes they return.

This requires exposing the `containsContact()` method to the `DatabaseComponent`
and is needed for finding out efficiently whether a contact already exists.

Modified the project structure, removed module extension and went instead for a non-complete core dependency graph

Semi-encapsulated the core/api dependency graphs and created a proper structure to load eager singletons

When more than one invitation socket is opened, Alice should pick which one to use and Bob should use whichever one Alice picks. This fixes a race condition where each party picked a different socket and closed the other.