input: Rework PointerFocus to operate directly on WlSurface

[Drakulix]

Continuation of #322 to eventually bump smithay again.

This takes about half of @ids1024 original approach, by leaving the KeyboardFocusTarget as is and adjusting the PointerFocusTarget to go all the way and split up CosmicMapped focus into iced-UI and surfaces.

Reasoning:

• The smithay changes actually don't require us to adjust the keyboard focus and I don't think consolidating into a single WlSurface variant is a good idea, as we are loosing context. The old PR spent quite a bit of code to reconstruct toplevel-surfaces. Let's simply not do that.
• The new pointer focus logic is meant to fix inconsistencies when wrapping multiple elements, regarding grabs, which suddently can't differentiate anymore between the individual elements (which in particular problematic for touch input). We have our fair share of weird workarounds and hacks in CosmicWindow and especially in CosmicStack to make the window unaware of the decorations and provide proper wl_poiinter events. All of this is brittle and in some parts even straight up buggy (for admittedly rare input combinations). Lets split the focus in the actual window surface(s) and the decorations to fix this.

Remaining TODOs:

• Rebase
• Currently this comments out the screencopy stuff inside the window-types, as there is no central location to get pointer events for a single window anymore. Lets fix this (somehow..)
• Actually upgrade smithay
• Incorporate tiling: Check for popups before tiles in element_under #341

[ids1024]

Seems good. I'm inclined to agree that consolidating things under a single KeyboardFocusTarget::WlSurface doesn't work out that well. Keeping them separate makes it easier to match on what the keyboard focus is, to prevent surface types that shouldn't get keyboard focus from getting it, etc. It makes TryFrom<PointerFocusTarget> a little harder to implement, but that needs to get the parent of subsurfaces anyway and perhaps then shouldn't be defined as TryFrom.

We can still make the keyboard target code less redundant with Smithay/smithay#1334. Then adding a variant or a new trait isn't too painful.

[ids1024]

SSDs still don't handle touch events, but it looks like that's expected. That can be added later.

[ids1024]

The changes all seem reasonable, and everything that I've tested is working fine.

[Drakulix]

SSDs still don't handle touch events, but it looks like that's expected. That can be added later.

Yeah, that requires implementing the TouchTarget for them and properly supporting TouchGrabs. Left that out for now, as I don't have a touchscreen to test that anyway.