Patches for review:

• https://github.com/wmde/WikibaseDataModelServices/pull/91 (merged)
• https://github.com/wmde/WikibaseDataModelServices/pull/94 (merged)
• https://github.com/wmde/WikibaseDataModelServices/pull/96

For the record, since there seems to be fundamental disagreement (here and here) on this:

• What you see in https://github.com/wmde/WikibaseDataModelServices/pull/91 is the result of part pair programming with @Jonas and me, part me alone.
• I started with the StatementGrouper interface and used it right away in the place(s) where we want to use it (see https://gerrit.wikimedia.org/r/254394).
• I started with a straight DataTypeStatementGrouper implementation that does everything itself, without any of the filter stuff. You gave it an array of data types in a slightly complicated but very flexible way, typically array( 'statements' => null, 'identifiers' => 'identifier' ), and it turned a single StatementList into two, the second containing identifiers, the first containing everything else. You can still see this early attempt here: https://github.com/wmde/WikibaseDataModelServices/blob/fa09526a60dfd50b7cbf3c575ca05e7edc2248ec/src/Statement/Grouper/DataTypeStatementGrouper.php.
• I was told by @Jonas and @adrianheine's original proposal in https://phabricator.wikimedia.org/T117421#1807403 I should try the filter approach. I did that and realized that the implementations are much, much nicer. Much more focused on a single responsibility per class. So I decided to split my original DataTypeStatementGrouper into a FilteringStatementGrouper and a DataTypeStatementFilter.

Other design decisions include:

• I found it very obvious that any grouping is wikidata.org specific and not a general Wikibase concept and can not be hardcoded. This dictated a lot of other decisions. Unfortunately the team does not agree on this, see https://gerrit.wikimedia.org/r/#/c/254394/3/view/src/ItemView.php, leading to friction and frustration.
• I decided to add the most basic implementations we discussed, even if we are not going to use them right away in the same story (T117421). One thing these implementations do is showing how the interfaces are intended to be used. And we already know we do have use for these implementations. Without them it would be almost pointless to put the two new classes in Wikibase-DataModel-Services. It would probably be pointless to have interfaces at all. The code could just live in MediaWiki-extensions-WikibaseView. I already explained this in https://github.com/wmde/WikibaseDataModelServices/pull/91#discussion_r46273418.
• I decided very early that the PropertySetStatementFilter must use string arrays, as they are given via configuration, instead of PropertyId objects. Converting strings to objects and back would just be painful (see https://github.com/wmde/WikibaseDataModelServices/pull/91#discussion_r45861944).
• I did an actual (micro) benchmark and decided that any array_flip is pointless, in all the groupers and filters (see https://github.com/wmde/WikibaseDataModelServices/pull/91#discussion_r46144199).

I added two points about configuration and PropertyId objects to my comment above.