Add <spec> arguments to cargo build/clean

[alexcrichton]

This is rebased on #617 as I wanted to use one of the functions added in the patch. Otherwise the details are in the commits.

[alexcrichton]

Hm, question. I'm thinking of just extending this to solve #483, but that raises questions with the CLI syntax for cargo test. I don't think we want cargo test <spec> because that'll conflict with cargo test testname_filter which is far more convenient. For that reason, I think that cargo {test,bench} want a -p, --package flag with a SPEC argument that specifies what to test/bench.

Given that, the other commands which support <spec> as a command line argument (as opposed to flag) is cargo {update, clean, pkgid, build}. I'm thinking that to be consistent, all commands should take -p, --package except pkgid and update which operate much more closely on dependencies than the other commands.

Does that sound sane?

[alexcrichton]

Updated with said comment and a fix for #483 as well.

[brson]

r=me

[alexcrichton]

I discussed this with @wycats on IRC, and he had two major comments:

1. The wording around ambiguous specifications should be something like:

There are multiple `curl` packages in your project. Please re-run ${command} 
as `cargo ${command} -p` and one of the  following:
  ${spec1}
  ${spec2}
  ${spec3}
  ...

1. To be consistent, all commands should take a specification via -p. This means that cargo update foo will be deprecated in favor of cargo update -p foo.

[alexcrichton]

Updated. re-r?

[brson]

r=me