Windows builds via GitHub Actions

[jkbonfield]

The AppVeyor builds have become slower to launch and they're also a bit slow on execution. GitHub Actions runs in about half the time.

Note this needs samtools/htscodecs#123 merging first, but for purposes of testing I just incorporated it in this PR via an extra commit to change the submodule commit. If the htscodecs PR gets modified in any way, changing the hash, then I'll update this appropriately.

Also, if you wish to see these tests in-situ here, we could copy this PR branch to samtools/htslib from jkbonfield/htslib as otherwise it won't enable the workflow. (As I did for htscodecs)

[jmarshall]

I was initially going to suggest a git config core.autocrlf-core.eol-etc step before the checkout step (on the basis that it would be better to affect only the action runner rather than all Windows users as adding to .gitattributes does), but after reading through actions/checkout#135 I have changed my mind. Fixing this for the test files for all Windows users is actually the right thing to do!

That's a long thread, but actions/checkout#135 (comment) makes a very good point that just doing a blanket ** -text that would also affect *.c files would be the wrong thing to do. So I'm glad to see this PR just does ‑text more specifically for a bunch of test file extensions.

[jkbonfield]

I confess for the Samtools one I gave up worrying about every little extension and just went for test/**, but I do accept there are some C files in there. I wonder if we can then do text/*.c +text or similar to reenable it as an exception to the blanket rule? I doubt it matters though tbh as I'm not convinced we'll be getting many, if any, PRs from windows developers, and even if so the code tools typically all support nl anyway.

[daviesrob]

Compared with the old script, we've lost make test-shlib-exports. Assuming it does actually work on Windows, it's probably useful to have.

[jkbonfield]

Good spot. I'm assuming it does work as it was in the appveyor config. I'll put it back and see what happens.

[jkbonfield]

Hmm, disappointingly adding back the test-shlib-exports now fails:

Checking shared library exports
kh_begin
kh_clear_##name
kh_del_##name
kh_destroy_##name
kh_get_##name
kh_init_##name
kh_put_##name
kh_resize_##name
ks_destroy
ks_getuntil2
ks_init
kseq_destroy
kseq_init
kseq_read
Error: Found unexported symbols (listed above)

I initially thought they're all erroneous things from the templates-in-C style of klib, but kseq_read is more normal, although it's still done as a macro with a SCOPE define. I'll need to dig deeper into what it's attempting to do and why we're no longer passing this script.

[jkbonfield]

Fixing the header checking perl script to cope with windows line endings worked. So I've patched that and done some rebasing and squashing of commits. Assuming it now passes this is ready for re-review.

[daviesrob]

As foretold, the htscodecs submodule commit needs to be adjusted. It also might be good to leave the AppVeyor configuration in place for now, for a less messy transition. Once the couple of recent pull requests that straddle the change have been committed, (#1797, #1799) we can turn it off in the settings and push a commit to remove the configuration.

[jkbonfield]

Ah yes I meant to update the htscodecs submodule and forgot.

I was assuming we'd just turn off the appveyor, rerun tests, and if it passed merge it. But we can do it in two separate PRs if really needed. It's minor fluff tbh.