Update smithay-client-toolkit to 'v0.15.0'

[kchibisov]

This commit also drops 'Theme' trait with its support types
in favor of 'FallbackFrame' meaning that winit will use some
predefined frame for the time being, since porting 'ConceptFrame'
will require adding font rendering librarires right into winit,
which is not desired.

[kchibisov]

Since sctk dropped ConceptFrame support new decorations are looking pretty awkward, however considering that other libraries (sdl,glfw) provide poor looking decorations, since everything else is 'complexity & bringing font rendering engines' I don't think that we should port old sctk code at all.

What winit can do is to provide abstractions to work with decorations surfaces and provide buffers to attach to them.

[kchibisov]

Added @vberger wrt calloop and decorations update.

[maroider]

Relevant issues:
#1967
Smithay/client-toolkit#196

[kchibisov]

@chrisduerr I've asked you on irc to review this PR wrt dropping fancy client side decorations, since it's affecting alacritty as the end user. I personally don't really care, since I don't like client side decorations as a concept and would use them purely for 'special' clients or debugging, but we have gnome, thus we're affecting them.

[chrisduerr]

I've asked you on irc to review this PR wrt dropping fancy client side decorations, since it's affecting alacritty as the end user.

I was aware of this already since I was around on IRC when @vberger decided that this was the best approach forward. I somewhat nudged him in that direction when persistently complaining about the font handling of existing decorations.

I think for sctk it makes a lot of sense and I'm not sure it makes sense for winit to step in and provide them. I'd say winit probably comes with similar issues as sctk and will likely fail to provide anything other than super basic decorations with awkward font rendering. So shoving it even further downstream at least should make that easier, since font handling is likely present there already (it is in Alacritty at least).

With an infinite maintenance budget I think this should definitely be handled above application level in winit. But unfortunately that's just not the case. So the approach makes sense.