[ci] use cross for testing

[gnzlbg]

This PR switches to using cargo cross for testing the library.

The main reason is that we need to be able to use qemu-system on arm build-bots to test run-time feature detection. But cross also makes it much easier to add build-bots for MIPS MSA, Sparc64 V SIMD, Altivec, iOS, Android, and it also allow us to test x86 using qemu (which we could use to test AVX-512).

[gnzlbg]

@alexcrichton thoughts?

[gnzlbg]

I have removed arm-unknown-linux-gnueabihf temporarily, it is currently not supported by cross but a PR is in progress.

[gnzlbg]

we need to tweak these two images slightly to pass the correct OBJDUMP.

[alexcrichton]

Er sorry for letting this sit! I'm personally sort of wary to pick this up though, would it be possible to game out first what testing would look like without cross?

[gnzlbg]

Without cross somebody would need to implement the infrastructure to use qemu-system here, which is no small feat.

AFAIK @malbarbo seemed to be interested into migrating the libc crate to use cross for testing. I think it is worth it to give it a test ride on the stdsimd crate first. cross will let us choose between using qemu-user or qemu-system easily, and makes it trivial to extend our ci to cover powerpc and mips.

[alexcrichton]

Having set up and maintained CI systems like this for quite a number of crates (and rust-lang/rust itself) I speak from experience when I say I'm wary of something like this. The CI needs of all projects tend to vary greatly especially around various particulars and are very difficult to share long-term as projects evolve. Eventually trying to share infrastructure ends up causing far more issues than it solves in my experience.

[gnzlbg]

Sadly it doesn't look like we have the manpower to add proper ci for the missing targets for the time being (without qemu-system run-time detection for ARM and PowerPC cannot be easily tested (qemu-user has some support for auxv though, but IIRC only via getauxval which we are not using yet).

I am closing this PR for now but will keep the branch sync'ed with master and update it to use qemu-system once it lands upstream. We can then re-evaluate.