Resolve symlinks during unpacking

[Patryk27]

Closes #230

Abstract

It's one of those one-byte-changes - during Git dependency unpacking, instead of:

cp -r $(dirname $toml) $dest

... what I'm proposing to do instead is:

cp -rL $(dirname $toml) $dest

... where -L tells cp to resolve symlinks - i.e. after this operations, symlinks will be substituted with the contents of the files they point at.

Overall, this will allow us to correctly compile packages such as maud that contain cross-workspace-package symlinks (e.g. this boi that points outside of maud_macros).

Without this fix, our new test would fail with:

error: couldn't read /nix/store/...-crates-io/dep/src/../symlink.txt: No such file or directory (os error 2)
 --> /sources/.../src/lib.rs:2:5
  |
  |     include_str!("../symlink.txt")
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

... and a similar error would be generated for maud, as can be seen in issue linked at the top.

Potential downsides

This fix resolves all symlinks - in reality, it should be enough to resolve only those symlinks that point outside of the currently processed crate; in my opinion that'd make the implementation more difficult for no apparent gain, though.

Caveats

For clarity, this pull request depends on #232; after that one gets merged, this PR should remain with just one commit inside of it.

[blitz]

@Patryk27 I've merged #232. Can you rebase this PR?

[Patryk27]

Ready! 🚀

[Patryk27]

This part is the same as for git-dep-by-branch-with-slash - for simplicity, I'm planning on refactoring it (i.e. extracting to some common function) in a separate commit later, after this PR.

[Patryk27]

In the meantime I've found a much better way to approach this issue, so let me close this merge request and open a new one 🙂