OSD capability

[fossfreedom]

Description

This PR reworks the previous mutter invoked OSD capability to be wayland friendly.

Now we specifically look for volume & brightness changes are display the OSD.
The volume changes are tracked in the same manner as the volume applet - i.e. GVC.
For brightness we grab the values straight out of the gsd component.

New here is OSD display when the caps-lock / num-lock keys are displayed. Very useful for small keyboards when you can easily press the caps-lock key accidentally. Note the comment in the keymap section of osdkeys where there appears to be a bug under wayland on first initialisation of the keymap - tests on X11 show the this code works just fine. i.e. if you press caps lock immediately on first login the OSD is not displayed. Quick test under Gtk4 and the equivalent standalone code for keymap initialisation works just fine. ho hum.

The old menus code has been nuked.

The daemon X11 stuff has also been removed - budgie-daemon is now running wayland not xwayland.

Submitter Checklist

• Squashed commits with git rebase -i (if needed)
• Built budgie-desktop and verified that the patch worked (if needed)

[fossfreedom]

Hang-fire on this - likely to strip the OSD capslock/numlock stuff because it the calls to libxfce4windowing ... get primary monitor calls appear to be freezing budgie-daemon.

[EbonJaeger]

I wonder if that's what caused a thread to be constantly at 100% the other day... I'd been trying to figure out what caused it, but couldn't get it to happen again.

[fossfreedom]

@BuddiesOfBudgie/best-buds ok - this is ready. The big issue I found is the way we are using libxfce4windowing.

If you either:

1. call libxfce4windowing.Screen.get_default() too quickly and/or
2. keep a reference such as a class variable to libxfce4windowing.Screen.get_default() and subsequently call the method somewhere else

Then its very very likely that budgie-daemon will end up spinning indefinitely at 100%. Running a gdb -p on budgie-daemon shows that the callout to the underlying wayland-client stuff (libwayland) performs a mutex-lock - two calls cause each-other to block and never completes.

Thus - we should limit our usage of libxfce4windowing calls throughout a process especially if the usage is impacted as described by 1/2 above.