ShellClients: Add PanelClient

[leolost2605]

This PR implement everything necessary for the positioning of Panels (currently top and bottom are supported) and their autohiding.

The API that is available (and in the future can probably be accessed via the wayland protocol) is:
set_anchor (Meta.Window window, Meta.Side side)
Pins the given window to the given side on the primary monitor and keeps it there centered. The side can be changed on the fly (at least in theory).

set_hide_mode (Meta.Window window, HideMode hide_mode)
with hide_mode being one of the following:

NEVER // exclusive, i.e. with struts
MAXIMIZED_FOCUS_WINDOW // hide if the maximized focus window overlaps the dock
OVERLAP_FOCUS_WINDOW // hide if the focus window overlaps the dock
OVERLAP_WINDOW // hide if any normal or dialog window overlaps the dock
ALWAYS // always hide

Gala will then handle autohiding taking into account hover and any open transient windows (e.g. popovers, menus, dialogs, etc.). It will also show the panel when the barrier at the appropriate side is hit.
This can also be changed on the fly.

This is enough to replicate the current X experience. It even supports autohiding wingpanel in theory (the example that's currently included here but will be removed sets up wingpanel to always hide and dock to dodge windows (OVERLAP_WINDOW).

It doesn't fully work/has some issues if run on mutter < 46

Also this of course only works on wayland

[leolost2605]

Regarding focus management I'd like some opinions on how we want to do it.
Mutters behavior currently is like this:
https://github.com/GNOME/mutter/blob/8a862b102c2d059ed498eeab5e4c7abb94bc5f1f/doc/mutter-focus.txt#L109
I.e. dock windows only receive keyboard focus if they specifically request it via NET_ACTIVE_WINDOW on X so they won't get any focus on wayland.
Should we replicate this behavior? I.e. add a focus method to the wayland protocol? This would also allow a focus grab without user interaction which might come in handy in some special cases?

FWIW wlr_layer_shell does it like this:
https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:keyboard_interactivity
(1:1 replication of this might need some upstream work and I'm not 100% sure this will get accepted given the things said in the document linked above)

Or maybe there are suggestions for alternative ways to handle this?

@tintou @Marukesu might have some opinions here?

[tintou]

Wingpanel actually requires keyboard focus for the application menu (?)

[leolost2605]

Yeah and it also might want to grab it when using super key to open it. Currently it just can't be interacted with on wayland