Auto merge of #4416 - Xanewok:more-executor-params, r=alexcrichton

Expose `Target` and `Unit` params to appropriate `Executor` callbacks

This effectively does only two things:
* Pass existing `&Unit` to `init()`
* Pass existing `&Target` to `exec()`s

Also updated doc comments slightly.

The `init()` is called for every `Work` preparation by `rustc()` and since it's not called once (not sure if intended?), it'd be good to include more information for which `Unit` the `rustc` process invocation has been initially prepared (I think more importantly it shows that `init()` is called many times for many targets).
Additionally, it'd be good to know about `Unit` compiled in the `exec()` callbacks in more structured manner (so the user doesn't have to parse the `ProcessBuilder` arguments and/or make certain assumptions) and since `target` was already cloned and moved into the closure, it was only a matter of exposing it.

I think it'd be ideal to provide all the necessary information to recreate a `Unit` but with a static lifetime needed for the closure, however this would mean cloning more data per-target ([`Kind`](https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_rustc/mod.rs#L41) should be basically free, however not sure if cloning [`Profile`](https://github.com/rust-lang/cargo/blob/master/src/cargo/core/manifest.rs#L151) is acceptable). With this, `Executor` users could query `Context` more easily (e.g. to get a unit dep graph! :smile:), as the API accepts `Unit`s in many places.

r? @alexcrichton
cc @nrc

EDIT:
This changes the public API, not sure if there's something else I should do about it, only ran `cargo test` locally.