Crates from git repos are vendored in a flattened directory where each crate shows up at the root of the vendor directory. Since the vendoring step effectively breaks workspace structures, any crates which use workspace inheritance (e.g. package.version.workspace = true will fail to resolve.
To work around this we inspect the crate's workspace manifest (if it exists) and attempt to manually merge the values while copying the contents to the vendor directory.
* Previously all build hooks were instantiated in a single
`callPackages` call which led to several issues:
- changes via `lib.overrideScope'` were ignored because the build
hooks were only ever instantiated with the nixpkgs instance of our
flake (not whatever overlays the caller may have made)
- the pkgs splicing was not done quite right, meaning when we pull in
the build hooks as nativeBuildInputs the splicing wasn't picking up
the overridden versions of `cargo` but was instead trying to
recompile the nixpkgs version each time
* Similarly rename `installCargoTargetDirHook` to
`installCargoArtifactsHook`
* The intention is to highlight that "install" implies "copy to output"
and not anywhere else
* Also avoids the potential confusion of "cargo target dir" (location of
cargo's artifacts) with "cargo target" (which is the target
architecture/platform we want cargo to build for)
* This hook was never a great implementation to begin with since it
would simply search the cargo artifacts directory for binaries and
libraries to install
* This isn't really great since if we have multiple builds (say one with
debug artifacts, one with release artifacts) it isn't exactly clear
which artifacts would get installed (or which will get clobbered).
* Now that we have installFromCargoBuildLogHook we can simplify the
options a bit and only have one main installation method. The caller
can always provide their own if they wish
* Reducing the parameter surface area for good measure, zstd compression
works pretty well and it seems redundant to support multiple ways of
copying the target directory around
* Hopefully the updated name should be more clear that we are inhering
some existing cargo artifacts and NOT inheriting something like
CARGO_BUILD_TARGET which refers to the host target being built
* If the source root contains a Cargo.lock file it will be used to
create a vendor directory
* Otherwise a (descriptive) error will be thrown describing how to
remediate
* The caller can, of course, manually specify their own `cargoVendorDir`
which will skip the default vendoring
