Prepare for multithreading

[Drakulix]

As part of refactoring the KMS code to allow for mirroring outputs (and generally not matching a single output per surface), I wanted to introduce proper per-thread rendering per surface.

This obviously leads to complications regarding access of the necessary window management code from various threads. This is an attempt of solving this mess, by moving the Shell behind an RwLock. (The idea being that rendering and parts of the logic will only need to read the state and can do so in parallel, while modifications require an exclusive lock.)

This has had a couple of consequences, one being, that the seats are now part of the state, which makes access inside the window management code easier. (And earlier attempt trying to introduce the lock without this ran into some ugly issues.)

Additionally all wayland event-loop related structs had to be moved out of the Shell, which is especially annoying for the WorkspaceState and the XdgActivationState, which are frequently needed (and now passed into) the window management code.

One attempt at solving this (long-term) within wayland-rs and smithay is here: Smithay/smithay#1384

This would also allow to limit the access of grabs (or the SeatHandler in general) to Shell, which would mean we could move all the ptr.set_grab-code inside Shell and simply the logic quite a bit.

Anyway this is good enough for now and seems to be working just the same as before. As per usual I will drive this a couple of days to make sure everything is sound, but given the large diff this shouldn't sit around for long.

[Drakulix]

@ids1024 I did a last big rebase before merge and had to move some parts of the new touch code around. Could you give this a quick check to see if anything related to touch has regressed?

[ids1024]

Touch grabs still seem to work.

Everything looks fine. Adding RwLocks and more clones is annoying, but I guess not avoidable if we want to have multiple threads. At least so far, it isn't too bad.