Draft: Introduce input grabs

There are certain things with exclusive input models, for example forwarding input events vs tabbox vs xdg-popup grabs, etc. In order to implement such things, input event filters are used. But their main disadvantage is that they don't abstract the exclusive nature of such input models well. The input filters are riddled with brittle focus handling code. In case of keyboard input, it's even worse.

The input grabs intend to fill in this gap. An input grab is responsible for handling input. This can be used to forward input to the client, or properly handle input in the task switcher, or implement different focus handling strategies in dnd initiated by xwayland and wayland clients, etc.

The input grabs don't replace the event filters.

---

Draft: There are still a few things left to finish:

• startGrab()/endGrab() functions, and provide some functions to notify when a grab is replaced by another
• drop DecorationEventFilter and InternalWindowEventFilter
• some generic way to forward input events to windows and decorations so one doesn't need to write a lot of code in every grab. At the moment, it's a mess. To make things worse, we have Decoration::DecoratedClientImpl, InternalWindow, and SurfaceInterface that can accept input. All have different types. It would be nice to have a common denominator. I think Item is the best candidate. It also makes sense to reroute input through the scene so it's consistent with the visuals.