Rename `rustc-private-link` to `build-utils`

[kkysen]

This renames rustc-private-link to the more generic build-utils, as more stuff is intended to be added, such as find_llvm_config. I think it makes sense to have a place for these kinds of build-related functions to live instead of duplicating them across the other crates and having subtle bugs between them (as we currently have between the FileCheck and llvm-config resolvers).

Any opinions on the new name? Something else similarly generic would work, too.

[fw-immunant]

A personal belief of mine is that utils is never a good name--if the code weren't useful, it wouldn't be written; if it's related to some given goal (i.e. "build", here, or even "linking rustc_private"), it should just be named after that. Otherwise, "utils" modules are just excuses to dump unrelated code together rather than organizing it semantically.

[fw-immunant]

As far as find_llvm_config goes, is there useful sharing of implementation details between that and the existing Sysroot struct? If we were going to put this crate on crates.io (I think this was mentioned at some point in the past), would it still make sense to group these together?

[kkysen]

A personal belief of mine is that utils is never a good name--if the code weren't useful, it wouldn't be written; if it's related to some given goal (i.e. "build", here, or even "linking rustc_private"), it should just be named after that. Otherwise, "utils" modules are just excuses to dump unrelated code together rather than organizing it semantically.

What would a good name be then? I'm not sure what else is in common between resolving sysroots, linking to rustc private crates, and resolving llvm-config. They could be in separate crates, but that seems like overkill to me. Also, rustc-private-link was a poor name to begin with, as it also was used just for resolving sysroots.

[kkysen]

As far as find_llvm_config goes, is there useful sharing of implementation details between that and the existing Sysroot struct? If we were going to put this crate on crates.io (I think this was mentioned at some point in the past), would it still make sense to group these together?

I don't think there's that much in common between the two of them. Our llvm-config resolver is quite specific to our use case (like special README.md instructions for it) and not general enough for crates.io.

Also, although we had talked about moving rustc-private-link to crates.io, I'm realizing more and more that that was actually a bad idea. The rpath linking is not portable across machines differing toolchain paths (e.x. between users on the same machine), so it has a major downside. Running as a cargo subcommand is the better way to do this. We still need the sysroot resolving code like in the rustc wrapper in dynamic_instrumentation/src/main.rs, but I didn't reuse the code there because I wanted better anyhow error handling, but bringing in a large dependency like anyhow for a build.rs is much less worth it. It's possible the sysroot resolving code should be refactored into a separate crate on crates.io with good error handling.

[kkysen]

Closed in favor of #641.