What are the goals and tradeoffs for the linux backend?

Nobody has claimed this yet.

We've discussed the future of our linux backend some in the zulip, and it was also mentioned in #1945. I'm opening this so that we can have a more permanent record of the possibilities, and the various trade-offs involved.

Here are some possible goals:
1. it should be possible to compile a druid project so that it will run on both x11-only systems and wayland-only (no xwayland) systems
2. it should be possible to compile a druid project so that it will run on one kind of system but not the other (in order to minimize dependencies)
3. druid programs on linux should take a short(ish) time to compile
4. druid programs on linux should have no C dependencies, to help keep the build process simple
5. druid-shell should remain small enough to maintain (i.e. not include a re-implementation of all of gtk)

Here are some possible ways to have a linux backend:

1. we maintain a gtk backend, and nothing else


2. we switch to using gdk, but not gtk


3. we have separate x11 and wayland backends,
   
   1. and we require choosing one at compile time, or
   
   
   2. we support runtime detection
   
   

Option a satisfies goals 1 and 5. (It satisfies goal 1 because gtk does the backend detection for us).
Option b might satisfy goals 1 and 5, and potentially also moves us towards goal 3.
Option c is harder to evaluate ahead of time, particularly as far as goals 3 and 5 are concerned.

I'm not 100% sure if goal 4 can be satisfied in a reasonable way. For example, if we want to support opengl on x11 then I think we *need* to link to `libX11`. Maybe we can load it at runtime, but anyway there are other hard-to-get-rid-of dependencies, like `xkbcommon` and `libinput`.

Are there any options or goals that I missed?

Start by reading issue #1945 and the referenced Zulip discussion, then compare the listed goals with options a–c and their trade-offs. Done means recording a settled direction for the Linux backend, including which goals and dependencies it should support; this issue does not name implementation files or tests.

Written by the indexing model from the issue text.