io::process::Command: add fine-grained env builder

[aturon]

This commit adds env_insert and env_remove methods to the Command
builder, easing updates to the environment variables for the child
process. The existing method, env, is still available for overriding
the entire environment in one shot (after which the env_insert and
env_remove methods can be used to make further adjustments).

To support these new methods, the internal env representation for
Command has been changed to an optional HashMap holding owned
CStrings (to support non-utf8 data). The HashMap is only
materialized if the environment is updated. The implementation does not
try hard to avoid allocation, since the cost of launching a process will
dwarf any allocation cost.

This patch also adds PartialOrd, Eq, and Hash implementations for
CString.

[alexcrichton]

If I were to design the API from the ground up at this moment, I would tend to say the the shorter-named env function would be used for building up the environment rather than overriding it. Overriding is a pretty dangerous thing to do as you have to ensure you keep all the important variables.

Cargo has a similar builder for the environment (predates Command), which has this signature:

pub fn env(mut self, key: &str, val: Option<&str>) -> ProcessBuilder;

For us &str would be T, but it made it such that we didn't need to have two functions, one for insertion, and one for removal. That being said, I find env("foo", "bar") quite convenient!

Hm, putting on the bikeshedding hat, what do you think of:

fn env<T: ToCStr>(self, k: T, v: T) -> Self;
fn env_remove<T: ToCStr>(self, k: T) -> Self;
fn env_override<T: ToCStr>(self, k: &[(T, T)]) -> Self;

Other than the naming (which may also be just fine), the rest of the patch looks good to me!

[aturon]

@alexcrichton Updated, using env_set_all rather than env_override.

I also updated some of the code using Command to use env rather than env_set_all, and made the signature for env a bit more flexible by allowing the key and value types to differ.

Let me know if you have any other suggestions!

[aturon]

@alexcrichton This is now passing on try. Take a quick look at the changes and send it to bors?

[alexcrichton]

This seems like another candidate for env over env_set_all

[aturon]

Note that the existing code zaps the entire environment to contain just $PYTHONPATH. Not sure if that was intended, but the new version keeps that behavior

[alexcrichton]

While I doubt that it was intended behavior, let's see what happens!

In general, it should probably continue to work, but it's also probably best to not nuke things like HOME and USER.

[alexcrichton]

But not critical at all, of course.

[alexcrichton]

I left two comments about where env may be more appropriate, but it's ok to fix later, so I'm going to r+ (neither is critical)