Local storage: provide a way to listen for changes of note counts per tag and per notebook

[d1vanov]

One use-case overlooked in the design of libquentier's local storage is the client code's need to track the changes in the number of notes per notebook and per tag: when the note gets updated, the client code needs to track on its own whether the note's set of tags has changed or not and whether the note has been moved from one notebook into the other one. It requires the client code to maintain the linkage between notes, notebooks and tags in memory for all notes, all notebooks and all tags. With large enough accounts the amount of memory needed to be spent on this is sufficient. Moreover, this requirement prevents the client code from workflows in which notes, notebooks and tags are loaded from the local storage lazily i.e. in small portions, not all at once. With large enough accounts the performance cost of having to do this is sufficient, at least on the app's startup.

If libquentier could provide a way for the client code to subscribe to the changes in the number of notes per tag and per notebook, then local storage component within libquentier could intercept the changes in these numbers on each note update and notify the client code about these. Thus the client code would be freed from the necessity to maintain the mappings between notes, notebooks and tags on its own.

How I envision it: new signals could be added to LocalStorageManager class, somewhat like this:

Q_SIGNALS:
    void noteMovedToAnotherNotebook(QString noteLocalUid,
                                    QString previousNotebookLocalUid,
                                    QString newNotebookLocalUid);
    void noteTagsListChanged(QString noteLocalUid,
                             QStringList previousNoteTagLocalUids,
                             QStringList newNoteTagLocalUids);

These signals are not tightly bound to the concept of note counts per tag or per notebook yet they provide the way to identify for which notebooks and for which tags the note counts have changed so the client code can either deal with the counts on its own (increment/decrement for relevant tags/notebooks) or re-request these from the local storage. On the other hand, some client code interested in such events for some other sake than counting the notes per notebook or per tag also receives a way to do its job in a much more lightweight way than maintaining all the mapping on its own.

[d1vanov]

Implemented in development branch.