wayland/toplevel: defer Toplevel/handle destruction to avoid use-after-free

[sunshowers]

Attempt to fix an issue where quickshell sometimes crashes on monitor wakeup. The stack trace can be found here.

Normally, when the V4 engine hands a QObject* to JavaScript it creates a QObjectWrapper guarded through the object's QQmlData. This allows a later delete to fire QObject::destroyed and to invalidate the wrapper.

But if the object is turned into a QVariant, it goes back to being a bare, untracked pointer with none of that functionality. This can happen if a Toplevel is embedded in a QVariantList or QVariantMap, such as what ScriptModel stores.

Now, if Toplevel and ToplevelHandle were then destroyed synchronously the moment the compositor closed a toplevel, a consumer holding the corresponding QObject* would hold on to a dangling reference. Accessing this later would then segfault.

This patch makes it so that both destructions are deferred with deleteLater(). This matches how screen wrappers are already freed in QuickshellTracked::updateScreens, and should hopefully fix this issue. (Note that this issue is only fixed on the read path, not the action path which still has a use-after-free. My thoughts are the action path is relatively rare, so it might be worth waiting to design a better fix for this which focuses on making invalid states unrepresentable, though naturally the ability to do so is more limited than it would be in a language with affine typing like Rust. One option is to do a larger rework like using a generational arena with indexes.)

Why must both Toplevel and ToplevelHandle be deferred? If Toplevel were deferred but ToplevelHandle were not, then Toplevel would be stuck holding a dangling pointer itself.

[sunshowers]

Spent some time looking at my crashing core in gdb and I'm now a bit less convinced that this is the issue I hit. Marking this as draft while I investigate further.

[sunshowers]

This is a partial fix but not a complete one, since raw pointers can be held for much longer than a deleteLater. See #879 for an attempted fix against the issue I actually ran into.