WindowManager/ShellClients: Explicitly override window group

[leolost2605]

To select the correct group for shell windows the window manager currently has to know what the possibilities are and then query the shell clients manager to see if the windows are one of that.
It also only works if we know the correct info about the windows before their window actor is turning visible.

Instead of this hacky solution we introduce a override_window_group in the wm. This is then called by the shellclientsmanager at that moment when it knows what the window will be.

This has a few advantages:

• We have a clear interface for how to handle changing the group of a window that also makes sure the wm knows about it and doesn't try to mess with it.
• It scales a lot better by allowing the actual places that know that the window should be somewhere else to change its group instead of the wm having to query everywhere. This will be useful for example with the osk which will also need its own group.
• It reduces the public api the shellclientsmanager has to expose
• It should finally fix the wingpanel sometimes being invisible in the multitasking view which for me still happens even after Move windows to shell group when window type changes #2646
• The second commit can remove some now unecessary code

[leolost2605]

@lenemter I've been thinking a bit more about it and maybe we should provide an enum of layers instead of allowing to provide any clutter.actor? What do you think about that? This would allow us to keep a bit more of an overview what layers exist and where goes what.

[lenemter]

@leolost2605 I think it's a good idea to put different windows into different layers and an enum seems to be a good and intuitive solution, so that's a 👍 from me

[leolost2605]

@lenemter all right I updated it and addressed the review comments so should be ready again :)

[lenemter]

It should finally fix the wingpanel sometimes being invisible in the multitasking view which for me still happens even after #2646

I still can reliable reproduce this issue, but I guess it's unrelated to this codepath