[WIP] Enable building on non-x86 systems

[mr-c]

• vcflib enable building on non-x86 vcflib/vcflib#292 Update to latest vcflib #2822 update to latest vcflib #3075
• gssw enable building on non-X86 with SIMDe gssw#27 update to latest vgteam/gssw #2906
• ssw enable building on non-x86 Complete-Striped-Smith-Waterman-Library#4 sync with vgteam's ssw HEAD #3023
• structures remove unnecessary -m64 structures#11 update deps/structures #2907
• dozeu Enable non-X86 compatibility dozeu#5 (upstream)
• libbdsg Remove unnecessary -msse4.2 libbdsg#72 update to latest libbdsg #2909
• fermi-lite vg dep: enable building on non-x86 edawson/fermi-lite#1 upstream: enable building on non-x86 lh3/fermi-lite#14

Fixes #2639

[adamnovak]

I don't think we'll be able to merge this as is even when it passes tests; instead of pointing everything to your forks of submodules, we'll want to merge your changes into our forks.

With Apple moving Macs to ARM now, building on non-x86 is more important. But we also rely fairly heavily on libraries like dozeu and GSSW that are written around compiler intrinsics for particular new-ish-x86 vector instructions that probably don't have exact ARM equivalents, or at least need some #define magic to select them.

We'll have to add slower, plain-C versions, or even ARM-vector-instruction versions, or just fall back to completely different core alignment code on ARM that isn't really vectorized but still lets it run.

@jeizenga You've been diving through the dozeu code; how would you rate making its vector operations swappable between SSE and NEON intrinsics, versus a C fallback implementation (or fallback C implementations of the intrinsics)? Does it use a lot of unique intrinsics or just a few?

[adamnovak]

We also don't always use byte order conversion when serializing/deserializing some of our file formats. It looks like arm64 as used in Linux is generally also little-endian, but before we let any big-endian ports out of the lab we need to do some serious interoperability testing to catch all the conversions we're missing.

[mr-c]

Hello @adamnovak .

The point of this PR is to use the https://github.com/simd-everywhere/simde header only SIMD library to gain compatibility for using the X86 SIMD intrinsics on non-X86 systems.

As you mentioned, there are only a few big endian architectures (for Debian they are s390x, sparc64, ppc64, and powerpc) and they can be safe ignored for now. If IBM or an IBM customer wants vg on a big iron system they they can pay for or contribute s390x big endian support themselves 😁

I agree that this shouldn't be merged until the git submodules are back to using the regular sources, not my forks. I'll add a checklist and link to the other pending PRs.

[mr-c]

Okay, the x86 build works and the tests complete. On arm64 the build completes, but some of the tests fail.

[adamnovak]

@mr-c Is there a way we can bring arm64 under CI? It's definitely going to break if we don't.

I think we might just be able to add Linux/GCC/arm64 to our build matrix for Travis: https://docs.travis-ci.com/user/multi-cpu-architectures/#testing-on-multiple-cpu-architectures

[mr-c]

Already part of this PR :-) https://github.com/vgteam/vg/pull/2867/files#diff-354f30a63fb0907d4ad57269548329e3R124