Separate backend from GroupModel and implement ContactGroupModel

Still TODO: Docs need updating for new classes, no tests for new classes (but GroupManager is tested throughly via GroupModel).

This is a big patch, but hopefully pretty straightforward:

All of the logic to query, modify, and track the state of groups is separated out of GroupModel into the new GroupManager. GroupManager works on GroupObject, which is a canonical QObject-based representation of a group that is otherwise very similar to (and interoperates with) the old value-based Group API. That allows for sane tracking of changes to groups by applications or models. GroupModel is then refactored on top of GroupManager, but its API is entirely compatible.

ContactGroup and ContactGroupModel were added, providing a very similar interface to GroupModel, but with all groups sharing the same contact information merged together under a single ContactGroup (from which you can retrieve an individual GroupObject). This allows combining multiple types of communication (groups) for the same contact in UI.

ConversationModel also received new API, to allow querying events from multiple groups.

All changes should be backwards compatible, and all new API should be considered experimental. We should look into making a larger API break for commhistory at some point in the future to move away from QAbstractItemModel-based API, but that's out of scope for now.