Support linking multiple crates with the same name within a single build rule

[acmcarther]

In order to implement #37, we'll need to be able to handle multiple copies of a crate, as crates are entirely recompiled and linked separately when they have different feature flags.

I suggest we do what cargo does: generate a hash that can be supplied to rustc's -C metadata argument for the purpose of disambiguation.

I wrote a prototype implementation that uses the rule's path for this purpose here, that I can use to prepare a "proper" implementation here.

@davidzchen Are there any issues you foresee in using the rule's path as a unique identifier for a crate?

[acmcarther]

I want to clarify this:

The underlying assumption here is actually incorrect! See this comment: rust-lang/cargo#2589 (comment)

Basically, when cargo resolves features, it unions them across the dependency tree. That means that if your crate root, depending on "foo" asks for "default-features=false", but your crate root depends on "bar" that depends on "foo" and permits the default features, your crate root gets them too! There is only one version of each rlib compiled for an entire workspace!

I believe we can close this, but I'd like to think on it a little more.

[acmcarther]

To add: This is actually the internal data structure they use to represent the dependency graph. Note, that the nodes, "PackageId", aren't specific to any set of features. All instances of "PackageId" must use on the same features.

[acmcarther]

This is addressed by #47 which needs a human to look at it.