Separate daemon and client in two separate programs

[LGFae]

The idea is to do all the reading, decoding, and resizing of the image in the client, so that the daemon just have to worry about animating it.

Benefits:

• lower memory usage, since the daemon won't have code it doesn't need (improves Support for "cleaning" the images from ram #28)
• isolated dependencies (the daemon won't have to depend on cli, or the image crate, etc. Also, the client doesn't have to depend on smithay)
• because of this, I will be far less reluctant of allowing some bloat in the client (since it won't contribute to the daemon's memory usage). This would make me far more willing to just allow for more image formats, even if they aren't totally supported upstream (Add support for avif and heif #45).
• Supporting reading the image from stdin #42 becomes trivial
• by separating the common code to both programs in a library, we can do stuff like running criterion benchmarks on our compression code (currently I am doing that in a separate, personal project)
• things will just be more organized in general

Problems: I've tried this a long time ago, but wasn't very familiar with cargo workspaces, which is why I abandoned the idea back then.

• speed. Last time, the client just too forever to decode and serialize an animated gif, which made it look like the processed hanged.
• more complex communication. In order for the client to know which size it should resize the image to, it needs to ask the daemon.

The speed problem can be mitigated by first sending just the first frame, and then decoding, compressing, and serializing the rest of the gif's frame, as the daemon plays out the transition animation. Furthermore, we can assure the user the process isn't hanging by printing a progress report, which can be silenced with a --quiet flag. This, of course, comes at the price of even more complex communication between the processes.

Finally, this would represent a big breaking change to all packagers. They would have to rewrite their packaging scripts (which would now install 2 binaries instead of 1). For the end user, things would be more or less the same, swww init would simply call the daemon instead of forking.

Overall, this is very complicated, but I think the benefits are worth it. I will see if I can implement it this December.

[LGFae]

Update: I have a minimal, barely working version. A LOT of things still need to be sorted out (including gif animations), and the code looks ugly as sin, but memory usage does improve, significantly.

[LGFae]

Update2: after implementing gif animations, I can confirm that, at least for me, memory usage for the gif I use has gone down from ~85MiB to ~35MiB. There's much to fix in the code, however (including pesky race conditions). As soon as I have a more stable version I will make a branch so others can have a look at it (if anyone's at all interested).