[New custom build] Implement the new custom build command

Does include:
 - The build script is compiled in `target/build/$pkg`, its output is written in the same directory in the `output` file, and it has `target/build/$pkg/out` available to write temporary files
 - The `output` files are later loaded by each rustc invocation and other custom build command, in order to retreive the rustc-flags or `DEP_` variables.
 - Internal rename from `plugin` to `for_host`
 - A different system for passing command descriptions to the shell (internal change)
 - Deprecation of the old custom build script system with a warning if it is being used

Does not include:
 - Support for `links`, I plan to add this after this PR is merged
 - `DEP_<links>_<key>`: You just need to uncomment a block of code, but this can't be implemented without support for `links`
 - Build dependencies, I plan to add this after this PR is merged ; this probably conflicts a lot with #735, if I implement this now, I'll need to rewrite half of the code when rebasing
 - Tests to check that `rustc-flags` are correctly passed to rustc, because rustc doesn't support the `-l` flag yet. I'll add this to the PR once rust supports it (or maybe even before if I compile the fork of rustc that has it).
 - The test supposed to check whether a custom build script failure triggers a compilation failure for the whole project is commented out, because I didn't find a way to get the name of the package to match the exact error message. **This will need to be fixed before merging**.
 - There's no feedback of the new system in the `Compilation` struct
 - The `build` directory is not used when determining the fingerprint, something that was apparently done for the `native` directory

I recommend reviewing commit by commit. I implemented each feature one by one (tests should pass for each individual commit).

cc #610

Targets end up having tons of filtering going on as they pass through the various stages of cargo, and in general I'm not too happy with the way they've turned out as the way they filter is often quite subtle. Using targets in this fashion may end up causing many surprises for commands like `cargo bench` and `cargo test` with custom build commands.

I do think that there's value in using a `Target` to leverage existing infrastructure in `ops::cargo_rustc`, but perhaps the `Target` should be generated at that time instead of way over here in TOML parsing?