Add the ability to pass environment variables to rustc

[smklein]

This patch enables callers to supply an additional
parameter to rust targets (such as "rust_library", "rust_binary",
etc):

rustc_env = [
"KEY=VALUE",
]

This parameter parses the key/value pairs, and appends them
to the list of environment variables supplied to rustc.

This parameter emulated the impact of "cargo:rustc-env=VAR=VALUE"
lines, which are common in build scripts.

[smklein]

For context, I've been trying to add an integration test of https://docs.rs/prost-build/0.6.1/prost_build/ into cargo-raze.

In this process, I've uncovered that the build script for this crate really wants to pass PROTOC as an environment variable: https://docs.rs/prost-build/0.6.1/prost_build/#sourcing-protoc

It can be supplied as an argument to the build script (which itself may or may not be enabled, depending on gen_buildrs)... but that build script turns around and emits a "cargo:rustc-env=VAR=VALUE" line, which raze + rules_rust ignores!

In the crate itself, the "env!" command is used (just like in the test added within this patch), and it refuses to compile without a compile-time value.

error: environment variable `PROTOC` not defined
   --> vendored/codegen_cargo_library/cargo/vendor/prost-build-0.6.1/src/lib.rs:680:15
    |
680 |     Path::new(env!("PROTOC"))
    |               ^^^^^^^^^^^^^^

error: environment variable `PROTOC_INCLUDE` not defined
   --> vendored/codegen_cargo_library/cargo/vendor/prost-build-0.6.1/src/lib.rs:685:15
    |
685 |     Path::new(env!("PROTOC_INCLUDE"))
    |               ^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

Personally, I think this is a value which should be parsed at runtime, not compile-time (and my colleagues have patches to prost-build pushing in this direction).

Regardless, it's inevitable that some crates will have "env!" macros, and this patch provides a mechanism for compiling them with an arbitrary env value.

[smklein]

Welp, I feel quite silly, I just realized #314 exists, and somehow forgot about it. Happy to abandon this patch in favor of that one, unless ya'll like string lists more than dicts in this context.

[tommilligan]

Hah, no worries. It's nice to see it's not just me that's run into this issue! And hilarious that we chose the exact same attribute name.

I do prefer the dictionary style as it avoids any issues with parsing, and it just ends up being a smaller diff.

[tommilligan]

This will fail for values that contain an = character, such as A=B=C, which should be parsed to ["A", "B=C"]. This could be fixed with

k, v = kv.split("=", 1)

[damienmg]

I would also prefer dict so PR #314 over this one.