CI: copy the crux-mir rlibs tree with tar

[sauclovian-g]

cp -r is producing inconsistent (and sometimes broken) results.

Fixes #1338.

[sauclovian-g]

That seems to have done the trick, the crux-mir build artefacts are all about 60M and the new Ubuntu ones contain the same files as the previous MacOS ones.

[RyanGlScott]

I accidentally ran into the same issue in https://github.com/GaloisInc/crucible/pull/1319/files#r1987985211, although I resolved it in a different way by just not copying them at all.

Alternatively, if we want to restore the previous behavior, we could implement a simpler solution: run cp -Lr instead of cp -r to follow symlinks. (This is what I plan to use in mir-json's CI—see GaloisInc/mir-json@3f91f8c.) I think that would be much simpler than using tar as an intermediate step, as is done here.

[sauclovian-g]

The standard/traditional way to copy a directory tree is tar-to-tar, which behaves reliably (unlike cp, which does not) so it should be this, not cp. cp options vary a lot and don't always behave consistently...

(for example, the macos cp(1) says "-L If the -R option is specified, all symbolic links are followed.")

[sauclovian-g]

(anyway for the moment we need a bindist that has the rlibs in it, even though #1319 is the way forward)

[RyanGlScott]

unlike cp, which does not

Can you elaborate more on this? Under what circumstances does cp -L not work reliably? I could certainly believe that it is not portable across operating systems, although I haven't seen as much in my CI testing in GaloisInc/mir-json@3f91f8c.

[sauclovian-g]

The MacOS man page suggests (but doesn't clearly state) that -L only works with -R. We could probably use -LR (rather than -Lr) since we don't need to care about running on legacy systems. But tar is really the standard way to do this...