refactor: unified thumbnails for board and document mode

[letsfindaway]

This PR is the result of my considerations about a rework of the thumbnail architecture initially started here: letsfindaway#190.

I have also created a wiki page describing the new architecture here: https://github.com/letsfindaway/OpenBoard/wiki/New-Thumbnail-Architecture. Let me just describe the core ideas here:

• Currently Board mode and Document mode have their own classes and implementations for the thumbnails. As both modes have to be in sync, there is a lot of error-prone code for synchronizing the thumbnails. just one example: if you add a page in Board mode, then you have to care that the thumbnail for that page is also created and kept up-to-date for the Document mode and vice versa. So the core idea is to have only one UBThumbnail class for both modes and to even use the same instances on the same UBThumbnailScene. Switching between modes then simply means re-arranging the thumbnails. You do not have to care about synchronization at all.
• The UBThumbnailScene is managed by a UBDocument class. This class has functions to create, delete, move and copy pages and takes care to invoke the UBPersistenceManager as well as to handle the thumbnails associated with the affected pages. One could cache instances of UBDocument together with the associated thumbnails. This makes switching between documents very fast.
  Note Currently all UBDocument instances are cached during a session. It is TBD whether a more sophisticated caching strategy is necessary and how it should look like.
  Edit I added a second commit implementing a ver simple caching strategy: Keep UBDocument instances and therefore thumbnails for documents which have been opened in Board mode in the current session.
• The different arrangement of the thumbnails in Board and Document mode is reflected in a UBThumbnailArranger with specific derived classes for the two modes.

The resulting code is much easier to understand and to maintain. And in fact it needs 500 lines of code less than before. Also the memory consumption for thumbnails is halved, as we need only one instance for Board and Document mode. Rearrangement of thumbnails is fast (50ms for 2000 thumbnails on my computer), so the holdoff timer to reduce frequency of rearrangements is not necessary.

The UBThumbnailScene uses deferred loading of thumbnail. This means that the user has no waiting time when selecting a document with many pages in Document mode. They can immediately start working with the document, even if more thumbnails are still loaded in the background.

I think that this PR is also a very good preparation for "Board thumbnails look like the last state of the view" and even more "Multiple documents opened side-by-side". The first idea benefits from the fact that synchronization is no longer necessary. The second one from the fact, that we have one thumbnail scene per document.

I also tested various aspects of the new implementation. Here is my test list: letsfindaway#190 (comment)

Here some more technical points:

• Use the same thumbnail items and the same thumbnail scene for Board and Document mode. Thumbnails are just rearranged depending on the mode.
• Create a UBDocument class for page handling. This class has functions for creating, deleting, moving and copying of pages. It takes care to call the proper functions on the UBPersistenceManager and to manage the thumbnail items. All other code shall only use these functions.
• Use a specific, concrete derived class of an abstract UBThumbnailArranger to handle the differences between Board and Document mode.
• Adapt the UBDocumentController and UBBoardController to the new thumbnails.
• Adapt the UBDocumentThumbnailsView and UBBoardThumbnails view to the new thumbnails.
• Remove cross-referencing includes in thumbnail views.
• Remove thumbnail pixmap handling from UBDocumentContainer.
• Fix keyboard selection in Document mode.
• Ensure last selected thumbnails stays visible when changing size.
• Re-enable the "Delete" and "Duplicate" buttons appearing when hovering over a thumbnail in Document mode. This was implemented, but did not work due to missing event forwarding.

It is probably worth to give just one example from the UBBoardController::addScene():

Before

    UBPersistenceManager::persistenceManager()->createDocumentSceneAt(selectedDocument(), mActiveSceneIndex+1);
    emit addThumbnailRequired(selectedDocument(), mActiveSceneIndex+1);
    if (UBApplication::documentController->selectedDocument() == selectedDocument())
    {
        UBApplication::documentController->insertThumbPage(mActiveSceneIndex +1);
        UBApplication::documentController->reloadThumbnails();
    }

After

    auto document = UBDocument::getDocument(selectedDocument());
    document->createPage(mActiveSceneIndex + 1);

[letsfindaway]

I just added a commit fixing issue #1171 which also occurred on this branch.

When the thumbnail palette is hidden, thumbnails are not live updated and are therefore outdated when the palette is shown later. We now reload a thumbnail from the thumbnail file when a scene was persisted and the thumbnail file was updated.

[letsfindaway]

Note: There were fears that lazy loading of thumbnails would conflict with adding or removing pages while thumbnails are not completely loaded. A further analysis shows: this is not the case.

• If a page was deleted during thumbnail loading, then the already loaded thumbnails above the deleted page are correctly shifted. Loading continues at the correct position, as it does not use a count, but just continues after the last loaded thumbnail.
• If a page was inserted during thumbnail loading, then the new page including its thumbnail are correctly inserted. as above, thumbnail loading continues at the correct position.

This works, because the renaming of files is a single, uninterruptible operation on the main thread.