Integrate GitHub Actions

[commonquail]

Define a GitHub Actions CI pipeline that builds for Linux on MSRV, stable, and next, and makes a half-arsed attempt at verifying MSRV on Windows.

Because several dependencies rely on wildcards the de facto MSRVs are a fair bit higher than advertised:

• getopts unceremoniously abandoned MSRV pretence in 0.2.20 and raised MSRV from 1.18 to 1.27, then again to 1.31 in 0.2.21.
• libloading 0.6.0 for "unix" uses MaybeUninit, which requires 1.36.
• libloading 0.6.0 for "windows" uses pointer::cast(), which requires 1.38, and the non_exhaustive feature, which requires 1.40.

Of course, the original MSRVs can be restored by fixing dependencies.

I've retained the Linux/Windows MSRV split out of precedence. It makes some sense given the build dependency difference, though I'd argue for simplifying communication by maintaining only one MSRV.

[commonquail]

I guess pull_request only triggers for incoming pull requests, not outgoing, so this won't run until the master branch push happens. You can see my own build history at https://github.com/commonquail/nvfancontrol/actions. It last built for https://github.com/commonquail/nvfancontrol/commit/d535e8e8096653ecd43f1a616f27a0e1967d5ca0, whose parent is https://github.com/commonquail/nvfancontrol/commit/15b8588989df6317c604deb2496585d41d07b487.

[commonquail]

... but I screwed up the message for 15b8588989df6317c604deb2496585d41d07b487 -_-.

[commonquail]

Well, https://github.com/foucault/nvfancontrol/commit/15b8588989df6317c604deb2496585d41d07b487 is now https://github.com/foucault/nvfancontrol/pull/19/commits/669dc3e473f2f57b0a88244c7ab2010571738a35, both of which point to https://github.com/foucault/nvfancontrol/pull/19/commits/bcfd45dff1dab1499944194ad0e7ec00a74ff8b0. Sorry for the mess.

[foucault]

Thanks for your contribution, although you may have realised that the floating versions on master make this kind of harder that it should be with regards to the minimum rust version we support. At this point I'm wondering what's the proper course of action: (a) pin the versions on master; (b) constantly increase the minimum rust version or (c) do CI only on release branches where dependencies are always pinned anyway. I tend towards (c) although it probably defeats the purpose of the "C" in CI ! Given that I'd rather keep master flexible wrt dependencies the only realistic solution is (b) although I'll admit that don't really know what's the "standard" course of action here.

[commonquail]

the floating versions on master make this kind of harder that it should be

Effectively impossible. I was going to submit another change to pin the remaining dependency versions for precisely that reason but hadn't gotten to it yet. Why do you want to avoid that?

I'm not personally inconvenienced by the minimum Rust version here (except for tracing it through a few misleading dependencies to determine it...). You could, for instance, just say "stable and nightly only", and get complete freedom from core Rust. That wouldn't prevent breakage by API changes in dependencies, though. It's quite trivial to make different build steps for master and release-*, too, for instance.

And at the end of the day you can always just reject this. :)