Don't propagate dataChanged upwards when we are not filtering.

Review Request #126789 - Created Jan. 18, 2016 and updated

Volker Krause
This avoids expensive layoutChange signals from QSFPM. We can only be sure
we are not filtering if filterAcceptRows isn't overridden, which we can
check if we assume sub-classes have the Q_OBJECT macro set.

This will however break sub-classes overriding filterAcceptRows without
using the Q_OBJECT macro, and using their own filter criteria. However,
this is a significant performance improvement in the common case of
KRFPM being used for string-based searching in a tree view, and the search
being unused.

Tested in GammaRay, where the layoutChanges are particularly painful as the source model is in a different process.

David Faure

I wrote extensive unit tests for this class.
1) does the unittest still pass?
2) if yes, then it should be extended to test for this case

  1. The unit tests all still pass here, I'll look into expanding the tests.