Add option to emit rerun-if-env-changed metadata

[nathaniel-daniel]

Partially fixes #230 by emitting directives for environment variables. Looking at #443, it seems uncontroversial to add an option to emit this metadata for environment variables.

This PR adds an option called emit_rerun_if_env_changed to control this behavior, defaulted to false. I added a check in getenv to print the metadata if this flag is true. Since I use the print function, cargo_metadata must also be true for this flag to have any effect.

[thomcc]

This is mostly good, but I'd like to avoid emitting this for the same var multiple times.

[thomcc]

This looks better. In the future it would be nice to avoid doing this for vars cargo sets on its own, but I don't know how much that matters.

[thomcc]

Thinking more, I'm really unsure why we wouldn't default this to true.

[nathaniel-daniel]

Thanks for the merge/fixes.

This looks better. In the future it would be nice to avoid doing this for vars cargo sets on its own, but I don't know how much that matters.

I figured it didn't matter too much, and wasn't sure how much overhead checking a list would be.

Thinking more, I'm really unsure why we wouldn't default this to true.

I was going off of #443 (comment) for this PR. I guess its conceivable that a build script may not support being rerun, so emitting rerun metadata might break those since I think cargo metadata is emitted by default. However, I couldn't find the exact rationale behind defaulting to false.

I wanted to create an uncontroversial PR to improve the situation around rerunning, since progress there seemed to have stalled for half a decade and I run into this issue a lot.

Also, is #230 considered fixed by this? Is there nothing that can be done for files aside from expecting the user to emit metadata themselves?