Wayland: Deduplicate cleanup logic

[deralmas]

We now reuse the global_remove event handler. This removes a considerable amount of duplication, minimizes human error (such as cleaning up a global in one place but not the other), and helps test the dynamic global removal logic.

---

NOTE: I think that the window cleanup logic in WaylandThread::destroy is broken. That said, the DS is supposed to clean all windows in the first place (and does so quite well), so I preserved it for now and added a warning. That'll do for now :P

[deralmas]

Oops I just noticed that we're iterating while removing elements from the HashSet. For some reason it works but I don't think that it's a good thing to do?

Edit: The HashSet header says:

/**
 * Implementation of Set using a bidi indexed hash map.
 * Use RBSet instead of this only if the following conditions are met:
 *
 * - You need to keep an iterator or const pointer to Key and you intend to add/remove elements in the meantime.

I'm afraid I might have ran into undefined behavior indeed, or at least something unpredictable. I'll fix this ASAP.

[deralmas]

Should be fixed, but I'm double-checking on my VM with some debug logging to make sure.

While RBSet should support this well with the common "Element loop" idiom, I chose to be double-safe and iterate on a copy of the keys, so that we're completely isolated from whatever happens to the names set. It's a bunch of extra allocations, but the average client receives less than a hundred globals and it's cleanup code.

[deralmas]

All right, no regressions on the usual compositors I test with. Everything should be good now, sorry for the mess.

[Repiteo]

Needs a rebase after #102987

[deralmas]

Done!

[Repiteo]

Thanks!