Remove special logic for binary dependencies (binary_deps)

[UebelAndre]

This is a followup of rust-lang/cargo#1545 where special support was added to account for binary dependencies in Remote genmode. It's unclear as to whether what the future of binary dependencies will look like for cargo but for this project, this issue should stand as a reminder that we're doing something unique and should at some point conform to whatever cargo decides to do.

rust-lang/cargo#1545 tracks a request to support a cargo clone command which can be used to clean up the implementation to support binary dependencies and reduce the amount of dependencies on cargo-raze.

Ultimately, once rust-lang/cargo#8708 is totally resolved then there will likely be an action item here. This issue tracks that progress.

edit: Updated issue since rust-lang/cargo#8888 is a duplicate of rust-lang/cargo#1545

[UebelAndre]

rust-lang/rfcs#3028 is also relevant here (and very exciting should it get approved and go through).

[UebelAndre]

I think there might be an easy path forward here. It would require updating the CrateContext list generated in the planning step to include an entry for the local package. Then some Bazel repository_rule could be written to take a url to some crate and download it and use. The rule would invoke cargo raze with some set of flags that cause it to render a build file for the local newly downloaded crate. This way we can clean up all the cruft created by the binary_deps functionality and the need for Cargo.raze.lock and be able to more directly rely/reuse existing cargo patterns. This might be the next thing I try to tackle. Interested in your thoughts here @acmcarther

[UebelAndre]

rust-lang/cargo#9096 can potentially be a resolution to this issue.

[UebelAndre]

For documentation's sake, this feature was added in #227