Provide necessary information for setting up window rules to the wayland compositor

### How to use GitHub

* Please use the 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to show that you are interested into the same feature.
* Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
* Subscribe to receive notifications on status change and new comments.

---

## Feature request

**Which Nextcloud Version are you currently using:**
33.0.7daily

**Is your feature request related to a problem? Please describe.**
As stated in #10119, Nextcloud windows appear at odd places under Wayland.

**Describe the solution you'd like**
Since Wayland does not let an app to choose where its windows appear, placement should be requested to the window manager / compositor instead. KWin has a notion of "window rule" to apply such placements to specific windows. Adequate rules should be supplied, or the information should be given to the user so he/she can do it.

Presently, getting the relevant information with KWin's GUI is difficult because the popup tray window disappear when it is engaged. I managed to infer that the window class is ``nextcloud com.nextcloud.desktopclient.nextcloud`` and the title is ``Nextcloud``. That lets me place the tray menu at the right place for my setup.

However, since the Share option window uses the exact same class and title, it is also placed at the same position when it pops up, which is undesirable.

Each kind of dialog/window should be distinguishable so that users and their compositors can place them adequately.

No files or tests are named. Start by locating the window and dialog setup for the tray menu and Share option, then check how their Wayland/KWin-identifying metadata is assigned. Done means each kind of window has distinct information that users and compositors can use for separate placement rules.

Written by the indexing model from the issue text.