Small redesign of filter and sorter ownership management

Filters and sorters are instantiated in a QML context, while
used inside the C++ one. They were attached to the SNI if they
didn't had parent, that could fix memory leaks. However, the
main problem is when filters or sorters are created in QML, and
destroyed.

A simple example is when some filters are created inside a QML
Page, and when that page got poped out of the page stack without
informing the SNI. The SNI might continue using the filters
even if they are already destroyed (their parents were the page,
and while being poped out, the page is destroyed). This situation
leads to segmentation faults.

In this commit, all filters and sorters that are attached to the SNI
are connected to a slot that remove them from the filter and sorter list
if they are destroyed.
Tests ...
Do not compile
Initial work on breadcrumb

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.

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.

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.

Please note that the implementation is not finished, and that
some cleanups, especially in the methods, is needed. The Facebook
interface also lacks of the support of notifications right now.