Rewrite project tree as a model/view set

[vkbo]

Summary:

This PR is a major refactoring of how the project structure is handled in novelWriter. The reason for this rewrite is that there are continuous problems with the current implementation where the core project keeps a set if all project items in a flat list, while the GUI component displaying the project tree is the only part with an up-to-date record of the order and hierarchy of the project items. In order to keep them consistent, the information must constantly be synched between the two representations of the project. This has worked reasonably well so far, but requires a lot of code, and it is very easy to introduce bugs into this.

In the model/view design, the project tree model is the only unit knowing the full structure of the tree. The model is a subclass of QAbstractItemModel, so it can be loaded directly into the QTreeView displaying it. Any change done in the GUI tree widget is done directly on the model. The core project tree class owns the model, and provides access methods and maintenance methods for other parts of the code that needs to change the model, and it emits signals on behalf of the model when the model is changed by the user on the GUI.

Having one central and complete model of the project structure also allows for some new features:

• Drag and drop is now fully controlled by the model, and therefore blocking actions that can mess it up is significantly easier, since it can be blocked on the very action taken, rather than intercepting it in the default implementation for drag and drop that was used before. The new approach also avoids several bugs in the Qt default implementation that had to be manually compensated for.
• As a consequence, the drag and drop feature has had a number of restrictions removed. The only thing it still blocks is drag and drop on the root level.
• The new drag and drop model also allows for dragging items from the project tree onto the editor and viewer to load the documents, in addition to all the other ways to open documents.

Due to the scope of this change, a 2.6 Beta 2 release is needed before moving on to a release candidate. A lot of features had to be re-implemented in the new model, and there may be bugs in it, or details missing.

Related Issue(s):

Reviewer's Checklist:

• The header of all files contain a reference to the repository license
• The overall test coverage is increased or remains the same as before
• All tests are passing
• All flake8 checks are passing and the style guide is followed
• Documentation (as docstrings) is complete and understandable
• Only files that have been actively changed are committed