[feat] Support wayland's layer shell initialization in Tauri via the Tao builder

[MarcosCosmos]

Describe the problem

I want to use Tauri to create "docked" apps (e.g. status bars) with wayland support, which generally requires the wlr layer shell protocol.

GTK provides support for this protocol but critically it requires initialisation before the window is first realised.

I investigated the codebase(s) for a while and discovered that the way Tauri and Tao work means that there's currently no convenient gap in the builder-based pipeline for this to occur.

Describe the solution you'd like

The simplest solution would be to provide a new builder property/config in tauri's WindowBuilder which can passed through to Tao's WindowBuilder allowing it to call the init_layer_shell method.

I've drafted a demo which I've been using myself and I'm happy clean it up and add tests to it etc as long as there aren't otherwise any objections or concerns with the proposal:

• Add Wayland layer shell prop to builders so it can be initialized (feat #1315) tao#1316
• Add Wayland layer shell prop to builders so it can be initialized (feat #15913) #15914

Alternatives considered

1. The main alternative to this idea is Access GTK window before it's mapped tao#925 + [feat] Window creation callback to mess with the native window #14277. However, it would be difficult, as there is already a window creation hook and it appears to necessarily fire too late to initialize the layer shell: https://github.com/MarcosCosmos/tauri/blob/7a8e94a1f383dbc8063540a89eade17e47eee7a6/crates/tauri-runtime-wry/src/lib.rs#L4590. (I'm happy be proven wrong on that though).
2. The workaround people are currently using is to transplant the WebView instance out of a tauri-owned window and into an unmanaged GTK window of their own creation.
   • E.g.: feat(linux): expose gtk_window method #2083 (comment).
   • However this is not how Tauri is supposed to work, and causes it's own problems.
     • It's noted to cause ghosting issues.
     • It also sacrifices various Tauri features that rely on Tauri managing the window, and complicates retaining access to the window in general.

Additional context

Companion Tao FR: tauri-apps/tao#1315

There are quite a few related issues across repos. A lot of them have been about the layer shell, but have previously been incorrectly closed due to existing post-creation access to the gtk window.

The highlights (which include some links above are:

• Something similar in tauri? andrewbaxter/wongus#4 (comment)
• Access GTK window before it's mapped tao#925 + feat: Add Linux method to use existing GTK window tao#938
• [feat] Window creation callback to mess with the native window #14277