Consider changing hashing behavior for executables.

[ehuss]

Cargo has some inconsistent behavior on whether or not it embeds a hash in the filename for executables. #8329 just changed it for macOS, and @joshtriplett pointed out we might want to choose a more consistent behavior across all platforms. Details are elaborated in https://github.com/rust-lang/cargo/blame/de31a3498dcf1641eaa619988df96321c66d2f8b/src/cargo/core/compiler/context/compilation_files.rs#L601-L634. In general, executables on Windows and macOS do not have a hash, and other platforms do. This is primarily because of embedded paths to their external debug information.

One downside of not including the hash is that Cargo is unable to cache multiple copies of the same executable. This can happen with different features and different rustc versions.

Another thing to consider is the impact on reproducible builds, where the filename may get embedded in some scenarios (needs some investigation).

Here are a few options:

1. Don't include the hash on any platform. Caching different copies of the same executable is probably a rare thing.
2. Place the executables into a hashed directory (like deps/bin-foo-64db4e4bf99c12dd/foo). I can't remember, but that may still be a problem on Windows which embeds an absolute path to the pdb file.
3. Leave as-is with the inconsistent behavior.

I'd probably lean towards 1, but I would like to get some experience with the new macOS behavior for at least a few months to see how annoying it might be.

There's also some discussions of supporting split-debuginfo on Linux (rust-lang/rust#34651). I have zero experience with that, but I'm curious if that would be impacted in a similar way.

[lilydjwg]

I guess I'll have some crates to be frequently rebuild because I put the target directory at the same place for all projects (to reuse across projects as well as put cache separate from important data).

Linux users are somewhat unique because they have btrfs/zfs/lvm snapshots and rsync.