Refactor OpenFile logic - make it gtk4-compatible

[bhennion]

This PR builds on #5585 and refactors Control::openFile and similar functions so that the dialogs they call become non-blocking and compatible with gtk4.

The logic is pretty complicated here. I tried to make it as easy to read and maintain as possible.
There are a couple of notable things to look at when reviewing:

1. I tried to homogenize the various file opening paths: e.g. the file version is now check even when the user selects a pdf-file, has the isAutoloadPdfXoj() setting to true and the associated .xopp file has an unsupported file version. This may have introduced unwanted behaviour changes.
2. Testing every scenario (e.g. Annotate PDF while having an unsaved document, or opening a file with missing PDF background,, or a combination of the two, and so on). I tried to test them all, but there are many and I could have missed one.
3. Implementation of xoj::util::move_only_function (similar to cpp23's std::move_only_function), used so that the callbacks can own an instance of std::unique_ptr, corresponding to the document being open. (For instance, if the file version is more recent than supported by this Xournal++ version, the document is already parsed, but we need to ask the user if they really want this document opened or not)
4. A question: if a file has not been saved yet and the user clicks on Open File, which dialog should pop up first: the FileChooser or the Save or discard dialog? I kept the same behaviour as on master (first the FileChooser) but I feel the other way around is more natural. Any opinion is welcome.

I also fixed a couple of inocuous bugs (e.g. if a file is not saved and the user tries to open a PDF file, the "Save or Discard" dialog appears twice on master).

For reviewers, only look the last commit, the other ones are from #5585 and will be rebased away once #5585 is merged. Edit: #5585 is merged and this has been rebased

There are still old gtk3-still dialogs in the code base. The next step is to refactor Control::save() and Control::saveAs(), in a follow up PR. Edit: this is now part of this PR

[bhennion]

I decided to include in this PR the changes to Control::save() and Control::saveAs() as well. My reasoning for this is: better to test as thoroughly as possible to end-state rather than test half-way through.

The changes here could have critical consequences I have not forseen, because non-blocking dialogs means non-blocking Control::save(), Control::close(), Control::openFile(). I tried to be as careful as I can, but thorough testing is required.

[bhennion]

resolved conflicts

[rolandlo]

I did some extensive testing (mostly on Linux, but also on Windows and MacOS) and haven't found any regressions. Good job! Two things I noticed (which are also present on master):

1. emergencysave.xopp is added to the list of recently opened documents, which doesn't make much sense.
2. When a file in the "new" format with PDF background like xournalpp/test/files/packaged_xopp/pdfBackground/new.xopp is emergency-saved, the PDF background cannot be restored via the emergencysave.xopp file.

From the code side I have only some minor remarks. Maybe @Febbe can take a look at move_only_function.h, since that takes a lot of C++ knowledge.

[rolandlo]

I think these two lines of comments (apparently without a clear purpose) should be removed.

[rolandlo]

I would go with option 1 as well. Priority has to be to avoid loss of data. Please update the PR description (you wrote there that you kept the behaviour from master, where the filechooser shows up first).

[rolandlo]

I really can't give you any feedback on this file (since I don't know C++ well enough). Maybe @Febbe can take a look at it.

[rolandlo]

Those two functions were removed.

Suggested change

	bool loadXoptTemplate(fs::path const& filepath);
	bool loadPdf(fs::path const& filepath, int scrollToPage);

[rolandlo]

This comment can be removed.

Suggested change

// bool close(bool allowDestroy = false, bool allowCancel = true);