[enhancement] Better cache and breadcrumb management

This commit is the initial work.

This commit introduces a refactor on the breadcrumb
and cache system, that will be described below.

SNI and SNIp are used to manage the cache and the paging
system. Other classes subclassing them should only use
the public methods that are provided to interact with
the cache.

Not all entities are cached. Only the important ones,
that derives from ICII are cached. The cache is actually
a QHash associating an identifier to a CacheEntry.

A CacheEntry is an explicitely shared class that holds
an optional identifier, a data stored as a QVariantMap,
and a pointer to the CII representing the data. A cache
entry is both used in the model as a model entry, but also
in the nodes for each page to store cached data.

The SNI creates the CII related to a CacheEntry only if
it is needed. It is done when SNI::data() is called.

A node is a combinaison of identifier and filters defining
an unique page in the application (or a collection of
data that should be displayed on an unique page). Since it
also represent an entity, a node also have a CacheEntry
associated to it, and a ICII that can be accessed.
A paging system is used to navigate between nodes:
SNI::nextPage() and SNI::prevousPage().

Populating a node is now done with populate(), and will push
a new node to the node stack. The new node stack silenty loads
while data from the previous node stack are still available in
SNI. In order to display the next node, SNI::nextPage() should
now be called manually.

The content of the node is synchronized with the data in
the cache. If it is reloaded with new data, the cache is
updated, and if the cache is updated, the ICII associated
to the node is also updated.

SNI::populate() should also be called manually now, since
a SNI don't react to a change of identifier and directly push
a new node. You have to do them manually with SNI::populate().

The signals, like SNI::statusChanged() errorChanged() are now
related to the state of the last node, not the currently
displayed node, so you might want to trigger a SNI::nextNode()
only when the loading is finished.

Implementing a SNI is now made easier. The whole caching system
is managed internally, and now, SNI::populateDataForLastNode()
SNI::populateModelDataforLastNode() and
SNI::validateCacheEntryForNode() should be implemented.

SNI::populateDataForLastNode() is used to trigger a request of
data for the last node. You can access to the information of the
last node using SNIp::lastNode(), that are the identifier and a
set of filters in order to create the network request for that
node.

When the last node is loaded, you need to load the related data
(data that will be displayed in the model). Implement
SNI::populateModelDataforLastNode() in order to perform the request.
Don't forget to call that method in the finished handler, to
continue the population while SNI::populateDataForLastNode() is
done.

Sorting is also implemented. So when the displayed data is updated,
it automatically invoke the filters that performs filtering on these
data in order for them to be presented in a natural way.

In order to set data (and automatically cache them), SNIp provides
a set of helpful methods, like SNIp::createCacheEntry(), that
automatically check if there is already a CacheEntry in the cache
and creates one if not.
Support for loading next and previous pages of results

This commit implements a paging system, allowing previous
pages of data and next pages to be loaded via the loadPrevious()
and loadNext() method in SNI.

It also includes modifications that allows the model to prepend
and append data to the different nodes. Facebook is fully
supported.

It finally includes fixes in the sorting method, so that the
data that is displayed is automatically resorted when sorters
are changed.
Better handle of filter destruction

This commit enable a better filter and sorter handling.

While a sorter is destroyed (often in QML context), it will trigger
a resort of the visible data.

While a filter is destroyed, it invalidates all the cached data
for nodes that used that filter. It is rather dangerous to
destroy filters dynamically, since there would be data-loss in the
cache. So it is better to destroy them if we know that we will
never use a node again, or do not destroy them at all.