get rid of four year old xcb dependency

[wucke13]

Description

This project ships a Cargo.lock (which is good, considering that it also is meant to be build-able as binary to provide the azul-dll), which unfortunately contains a very old version of xcb. This very old version of xcb generates code into the cargo-vendor-dir, which makes it impossible to compile azul in the nix ecosystem, since the cargo-vendor-dir resides in the read-only nix store, causing any attempt to write a file to it to fail. Generally I think its also considered just wrong to write to the cargo vendor dir, there is an environment variable for where to generate artifacts (OUT I think?).

Edit: This dependency is introduced via azul-desktop/clipboard2, which hasn't been touched in the last 4 years and pinpoints x11-clipboard to version 0.3.0-alpha.1, which again is 4 years old and has reached version 0.7.0 by now. I think it would be good to update some of the transitive dependencies of the stuff involved.

[fschutt]

I've seen the issue, but I'm currently hesitant to merge it before I don't have static linking implemented as the default option (so that people don't have to use Azul.dll in Rust executables anymore).

I think I also wanted to remove xcb because I wanted Azul to be dependency-free on Linux.