libtakmanager/launchertasksmodel: use better menuId lookup

Reason for the change

When pinning a launcher to the task bar from outside (kicker/kickoff or drag&drop), libtaskmanager tries to find the menuId so it can pin them as applications: urls, rather than the specific file system paths they have at that moment. The problem is that it only handles symlinks in one direction: if the new .desktop file is a symlink of an actual .desktop file that lives in an applications directory (which are what ksycoca indexes). But with Flatpak we instead have these files being symlinks (through several levels of indirection) to real .desktop files that live elsewhere. This means that attempts to pin one of these will generally fail, as they will use either the applications directory paths, or even a mixed one where some symlinks are resolved to their targets and others are not.

To fix this, we add two more options. The first handles the case of using the "Pin to task manager" function in kicker/kickoff) just uses the url as passed in, which is already correct, rather than resolving it to find the actual .desktop file. The second is for drag&drop from elsewhere; we resolve the final canonical path, take its .desktop file name (which has to be the menuId if this is a desktop file from an applications directory), and look that up via KService. If both point to the same file, we have a match, and can use the menuId. If none of the approaches work, we're looking at a .desktop file that is not in ksycoca.

Test plan

Right-click a flatpak app in kickoff, "Pin to task manager". (The kickoff widget needs to be on the same panel as a task manager widget).

Look at the id that's pinned in appletsrc.

Unpin it, then drag it to the task manager from kickoff.

Look at the id that's pinned in appletsrc.

Screenshots or screen recordings

N/A

Bugs fixed

BUG: 505066 FIXED-IN: 6.8.0