Match StartupWMClass to the window app_id so the icon is found

On Wayland the compositor picks a window's icon by matching
xdg_toplevel.app_id against an installed desktop file. GTK derives that
app_id from the executable name, so the app announces
app_id="slic3r-app-launcher", while the desktop file declares
StartupWMClass=prusa-slicer. That was the 2.x binary name; 3.0 installs
slic3r-app-launcher and no prusa-slicer binary is built any more. The
Exec line in the same file was updated for the rename but
StartupWMClass was not.

Nothing matches, so the window gets a generic icon instead of the
PrusaSlicer one. X11 is unaffected because matching there goes through
WM_CLASS, which wx sets from the application name rather than from
argv[0].

Point StartupWMClass at the app_id that is actually sent.

Setting the program name explicitly with g_set_prgname() would be the
other way to line these up, and would allow a nicer app_id, but it also
changes WM_CLASS on X11, so it is left alone here.

Author: xarbit

src/platform/unix/com.prusa3d.PrusaSlicer.desktop.in

@@ -9,4 +9,4 @@ MimeType=model/stl;application/vnd.ms-3mfdocument;application/prs.wavefront-obj;
 Categories=Graphics;3DGraphics;Engineering;
 Keywords=3D;Printing;Slicer;slice;3D;printer;convert;gcode;stl;obj;amf;SLA
 StartupNotify=false
-StartupWMClass=prusa-slicer
+StartupWMClass=slic3r-app-launcher