upgrade ar crate so we can do less copying when trimming rlibs

[froydnj]

The current trimming of rlibs in the dist-sccache case looks like:

1. Find the rust.metadata.bin file in the rlib (archive).
2. Read its data.
3. Create a new archive that will only contain said file.
4. Copy the data into the new archive.

We can do better than this, by doing the following:

1. Find the rust.metadata.bin file in the rlib (archive).
2. Create a new archive that will only contain said file.
3. Copy the data from the original rlib directly into the new archive.

We thus save a copy.

All that being said, it looks like recent versions of Rust don't
actually output rust.metadata.bin files into rlibs...unless we ought
to be only taking the lib.rmeta file that lives inside the archive.
But that would be a separate fix. (It's also great that we're seemingly
copying the rmeta file twice, once because it lives in the rlib and once
because it lives on disk as a separate file...)

[froydnj]

FWIW, it looks like rust-lang/rust#66235 changed the filename inside rlibs, so sccache should be updated to handle that. I'll do that in a separate PR.

[luser]

This is probably not actually useful since Rust 1.38 shipped with cargo enabling pipelined compilation. The point of this code was to ship less data over the wire for distributed compilation but now cargo will use the rmeta file for non-linking compiles (the only sort sccache can distribute anyway) so it shouldn't ever be necessary to strip data out of rlibs.

[froydnj]

This is probably not actually useful since Rust 1.38 shipped with cargo enabling pipelined compilation. The point of this code was to ship less data over the wire for distributed compilation but now cargo will use the rmeta file for non-linking compiles (the only sort sccache can distribute anyway) so it shouldn't ever be necessary to strip data out of rlibs.

Does that mean sccache should stop shipping the rlib entirely? That would be even better than rlib trimming!