Add workflows to test OCaml trunk on Cygwin

[shym]

This branch is finally getting mergeable.
Unfortunately, running the test suite on Cygwin takes so much time that it never fits into a single 6-hour run, so this PR proposes to add two workflows, each handling about half of the tests.

Still, I’d like to avoid repeating work as much as possible, in particular building twice the compiler and the dependencies (which take about 50 minutes in all the test rounds I ran...). So the way it is currently split up is:

• one workflow (Cygwin 1), with its cygwin input variable set to “initializer”, will build the compiler and the dependencies and create a cache entry with all that as soon as they are ready, before starting the tests per se,
• the other workflow (Cygwin 2), the “waiter”, will sleep for an hour if it does not find the cache entry it hopes for and then retry to fetch from the cache; if it fails again, it will fail the whole run (rather than try to build the compiler after already one hour of timeout lost).

Another possible (if I understood correctly github docs) strategy would be to set up the second workflow as triggered only when the first one completes. It would be slower but it would be simpler and quite possibly more robust (if the two workflows are not started at the same time, for instance when the runners are quite busy, the waiting strategy will fail).
@jmid: do you have any preference between those two options?

[jmid]

First of all: thanks for this well-structured and carefully prepared PR 🙏
It is really great to be able to include a Cygwin CI target!

do you have any preference between those two options?
I may have a slight preference for the second option (which the documentation CI flow may actually use under neath the hood). However I don't think that should hold us back from merging this PR.

I suppose it is the Unix-emulation of Cygwin (and perhaps some inefficiencies in there) that is causing this difference in execution speed? I hope that we at some point will get profiling tools to figure it out...

Anyway: How can we get a nice CI status badge of the output into the README? For the first/second or both?

[shym]

I may have a slight preference for the second option

I had a go at this option, as an attempt to get one badge for both workflows (on my branch cygwin-7) but I must have missed something in the documentation: the second workflow didn’t trigger when the first one finished.

I suppose it is the Unix-emulation of Cygwin (and perhaps some inefficiencies in there) that is causing this difference in execution speed?

I suppose so. Cygwin has clearly a lot of work to do to map POSIX expectancies on Windows API.

Anyway: How can we get a nice CI status badge of the output into the README? For the first/second or both?

I finally added both in a new commit as I failed two attempts (cygwin-6 and cygwin-7) to create one workflow whose final result would cover the complete test suite. I added them on a new line, since they are trunk-only. But as the lines are already overflowing, they might just as well be added to the trunk line?

[jmid]

The CI failures were unrelated:

• 1 flaky GitHub actions
• 2 flaky Thread mode tests (1 Win bytecode Queue test failing unexpectedly, 1 Cygwin CList int64 negtest taking forever)

I'll therefore merge.

[jmid]

The #311 CI workflow for Cygwin 2 failed with

Run actions/cache/restore@v3
Error: Failed to restore cache entry. Exiting as fail-on-cache-miss is set. Input key: 3cac9465be888e4a5895ab22ca2853b18299cd6c-cygwin-opam-ocaml.5.1.0

https://github.com/ocaml-multicore/multicoretests/actions/runs/4469170087/jobs/7850901158?pr=311

Is this expected?