This PR creates a new function closestCanonicalPath that behaves like QDir::canonicalPath, except that it will try to resolve symlinks for the nearest existing directory in the path if the path passed as an argument does not exist. For example, if /symlink points to the directory /target, then QDir("/symlink/example.txt").canonicalPath() and closestCanonicalPath("/symlink/example.txt") will both return /target/example.txt if example.txt exists. If it does not exist, then QDir::canonicalPath will output an empty string while this new function will still output /target/example.txt.

The motivation for this new function is twofold. It can be used to greatly simplify the implementation of validateDataPath, which was much more complex that it would seem on first glance and I suspect did not handle certain edge cases correctly. Secondly, this new function can be used in some unit tests where comparing file path strings was failing because one or more of the directories were symlinks. Existing canonical path functions could not be used because the actual files were not created for the tests.

This supersedes the changes made in #1928 to try to fix the unit tests. In my opinion, validateDataDir is not the correct function to use in that situation. The intent of validateDataDir is merely to make sure that project file paths do not refer to locations outside of the data directory. But for the failing asserts, what we want to test is that the file path stored in the keyframes points to where the actual files would be located if it was a real project. Equivalent filesystem paths should always resolve to the same string with closestCanonicalPath and thus should be safe to use string comparison with.