New semantics for `--features` flag

[matklad]

Historically, feature-related flags like --all-features,
--no-default-features and --features operated on the current
package. That is, cargo --package foo --feature feat would activate
feat for the package at the current working directory, and not for the
foo package. -Z package-features flag implements the more obvious
semantics for this combination of flags. This changes behavior, and that
is why we want to start with an unstable opt-in. The changes are:

• --feature flag affects the selected package. It is an error to
  specify --feature with more than a single -p, or with -p outside
  workspace (the latter could work in theory, but would be hard to
  implement).

• --all-features and --no-default-features affect all selected
  packages, and not the one at cwd.

• The package in cwd is not implicitly enabled when doing feature
  selection. That is, cargo build -Z package-features -p foo could
  select less features for various packages than cargo build -p foo.

r? @alexcrichton

[alexcrichton]

@bors: r+

Nice!

[bors]

📌 Commit 8d0b31b has been approved by alexcrichton

[bors]

⌛️ Testing commit 8d0b31b with merge 008c369...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 008c369 to master...