Make the CI script more generic and robust.

[xStrom]

As has been noted in #1 the glazier CI has been mostly a rough port of the druid-shell CI script. Recently, mostly thanks to @waywardmonkeys, our CI scripts have received some improvements. This PR here pushes that forward some more by incorporating some druid-shell post-fork changes and also a few other lessons from running the Druid CI over the years.

Changes

• The script now has a short name, CI, instead of the automatic .github/workflows/ci.yml to reduce UI noise.

• Everything is more generic, which means the script has e.g. --workspace which has no practical effect for Glazier at this point in time. The goal is to have a more easily syncable generic Linebender CI with minimal required changes per repository.

• Wayland no longer receives a separate job and instead gets tested using the general process.

  The original reason why Wayland had its own job for druid-shell was because we had GTK, X11, and Wayland to test which meant that the Linux job ran significantly longer than others. With GTK gone that reason has withered. Now the counter argument to have a single Linux job is stronger. Most of the common dependencies are already built for X11 so the additional building needed for Wayland is small. Also this helps reduce the GitHub job cache eviction pressure by no longer saving ~430MB per Wayland test run of essentially duplicate artifacts.

• Removed libx11-dev & libpango1.0-dev from the dependency setup. The former is preinstalled already, the latter is no longer required.

• Updated windows-2019 to windows-latest which currently translates to windows-2022.

• Run clippy with no default features, then default features, then all features. This doesn't have too much of an impact on time spent, because the follow-up stages can reuse most dependencies that were built in an earlier stage.

  As for motivation, imagine a scenario where glazier depends on lib_a and optionally on lib_b. Glazier code using feat_a of lib_a works fine, because lib_b enables lib_a::feat_a. However when lib_b is no longer included, code unexpectedly breaks. This has happened in practice with Druid and so doing more granular feature testing helps avoid it. Of course in a perfect world we would test every feature combination. However for regular CI I think starting with these three options should help catch most cases.

• Removed beta toolchain jobs. The original motivation for these was to catch clippy errors early before they hit stable. Now that Update rust ci version to be explicitly numbered #76 is merged and the strategy is to explicitly update the toolchain version, there won't be any sudden breakage that these beta jobs were meant to combat. So we can just remove them.

• Documentation code tests no longer have a separate job and are instead run as part of the general testing path.

• Documentation itself is generated using the nightly toolchain, because that is what docs.rs uses. This is another learned lesson from Druid where docs were fine with the stable toolchain, but then after publishing the crate the online docs were broken. Best to catch that earlier.

• Added back doc generation tests for Linux.

---

Fixes #1

[waywardmonkeys]

Yes to all of this. These are great changes.

[jaredoconnell]

Since we're trying to reduce the fragility of the CI, wouldn't it be a good idea to lock the OS major versions, instead of latest for Windows, Mac OS, and Ubuntu? I expect Ubuntu to be the most likely to have packages change, and I expect Windows to be the most stable.

[xStrom]

It does make sense and I wanted to do it, but you either have to manually update all the references (not that bad with search/replace) or reference a special variable that has to be defined by a repo admin in the github web UI. So I left it out of this PR at least.

[DJMcNab]

This doesn't seem to give any feedback for warnings. Do we want a solution for that?

[xStrom]

For some warnings, probably. However there are also warnings due to rustdoc limitations that we can't do much about. Like when two different structs have the same name and generate a html file name collision.

Although I guess we can maybe enable treating warnings as errors, and then disable them per-repo where we encounter warnings that we won't solve.