* Using substitutions for build hooks is a great way to ensure the
necessary utility is present without making the caller supply it to
the builder, except it makes things confusing when applying overrides
* For example, the `installFromCargoBuildLog` hook was inadvertently
ignoring any `cargo` overrides applied to the entire `lib`
instantiation
* By removing all explicit substations we also side step the issue of
trying to select the correct build/host/target version of the tool and
use whatever is present in the build environment
This is done to avoid breaking builds by including puts happen to have
setup-hooks which try to claim the configure phase (such as `cmake`).
The old behavior can be brought back by setting `configurePhase = null;`
on the derivation.
* This allows for fewer assumptions about the project structure
* The old behavior can easily be brought back by setting `cargoExtraArgs
= "--workspace";` in any derivation
* 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
