Implement UX for showing and answering private group invitations
As usual, this MR contains several logically separate commits that could be split out into smaller MRs if desired. It consists of two main parts:
* Showing open invitations in the list of private groups with a snackbar
* Showing invitations and responses in the private conversation
For both parts, the existing code was refactored to allow for a smooth implementation and to leave maintainable code behind.



Closes#707
See merge request !357
ProtocolStateException for client protocols
Methods that implement local actions in a client protocol (for example, accepting an invitation) can throw this exception to indicate that the action wasn't taken because the action isn't applicable to the current state. This can happen if the protocol state machine is updated by an incoming message and the user takes an action before the UI has been updated.
See merge request !368
Disable EmojiTextView software layer rendering when cache is too small
This needs to be tested if it works as intended on several devices.
See merge request !362
Limit scene transition animations to API 23 and above
to work-around [android bug #224270](https://code.google.com/p/android/issues/detail?id=224270).
This is only necessary if the transitioning view might not be available anymore when the exit transition is made.
Closes#686
See merge request !361
Implement UX for creating a private group
This MR allows the user to create a new private group and select contacts to be invited into the group.
There are currently 6 commits starting with some small refactoring for code reuse and making more functionality available in the backend. Each commit could be split up into a dedicated MR if desired.

Closes#661
See merge request !353
Fix race conditions when updating UI from events (again)
This is my second attempt at fixing race conditions caused by updating the UI from events while background tasks are loading data from the DB. Unlike my first attempt, this one is pretty simple and doesn't require too much reasoning about possible races.
The first commit fixes a few list loading bugs I found while working on this problem, and moves the lifecycle callbacks from resume/pause to start/stop, closing #609. The second commit contains the fix for #705, which works as follows:
* Each BriarAdapter has a revision counter
* Before making a change to the adapter that could be overwritten by a background task, increment the revision
* Before starting a background task that could overwrite other changes, get the current revision
* Before applying changes from a background task that could overwrite other changes, check whether the revision has changed
* If the revision has changed, restart the background task
* Otherwise apply the changes
Closes#609. #705 remains open because the PagerAdapters for blogs need to be updated.
See merge request !356