Vendoring story sucks!

[acmcarther]

This is caused by cargo2bazel being really unpolished. My ideal vendoring setup:

• //third_party/cargo2bazel only contains overridden dependencies, honored as described in Formally support overriding automatically derived dependencies. cargo2bazel#14
• Cargo.toml and Cargo.lock stay committed in repo

Then, for new contributors, the steps are (following acmcarther/cargo2bazel#16)

1. cargo install bazel-vendor
2. cargo bazel-vendor
   This will generate the exact dependencies for your platform (following Support [target.*.dependencies] directives cargo2bazel#13) into your third_party directory.
3. Develop as normal!

[acmcarther]

As described in the roadmap issue, in the taxonomy of the build:

crate dependency management
a build planner
a build execution engine

My ideal solution is

1. Cargo acts as the crate dependency manager
2. Custom cargo subcommand acts as the "build planner" up to the crate boundary. That is to say, explicit Cargo.toml dependencies get exposed, and their usage is dictated as normal in bazel, but below the surface, a cargo aware application performs planning
3. Bazel executes the build.