Use buffered caching in EntityTreeModel

Before this patch, if a new resource with many items was added to
Akonadi, the monitor would emit signals notifying of the new Items
available. If the new resource is for an imap account, for example,
this could mean notifications for a great many Items, even if they
are not represented in a view.

This patch causes reference counting to be used for Collections,
so that if the ETM is populated lazily, and a Collection is
selected, its items will be fetched (This is old behaviour), and
its reference count will be increased (This is new behaviour). If
a Collection is unselected in a view, the reference count is
decreased.

If the reference count of a Collection drops to zero, the
Collection is put into a buffer of a predefined size. Currently
the size is 10. When the buffer is full, the items in one of the
Collections might be purged from the model. The Collection whose
items are purged is determined by a first-in-first-out system,
where the Collection which has been in the buffer the longest
(without being selected again) is the first to be purged.

I wrote above that the Collection 'might be purged'. If the model
already has fewer than a set number of items in it, there is no
need to remove/add items every time the buffer is filled. Currently
if the model has fewer than 10000 Items, the Collection is not purged.

As a nice side effect, favourite collections (those represented in a
FavoriteCollectionsModel) are always fully up-tp-date and populated.

For the Application developer, the only thing that needs to be done
to use this feature is to use an Akonadi::SelectionProxyModel instead
of KSelectionProxyModel and use LazyPopulation.

This should fix the slowness reported in bug 208555, but I don't know
about the progress stuff.

CCBUG: 208555
REVIEW: 1789

svn path=/trunk/KDE/kdepimlibs/; revision=1031825