Manipulate shell scripts as bytestrings

canonical_cargo_home is a bit of an odd function - it transforms any non-clean unicode characters in a bid to make the path printable. This matters when e.g. folk have paths on disk that are in SHIFT-JIS but their encoding is in CP1252 or other incompatible combinations.

So rather than using this function designed for display, call cargo_home()?.join("bin").to_str(). Factoring out a helper for that is just about a common enough thing to be worth doing, but I haven't gotten around to it yet.

If to_str() fails, then we should fail to write the env file for now (as it would be written with bogus content). A more sophisticated iteration of this work would be to write the env file as a bytestring, not unicode, so that we can write it even if cargo_home isn't valid unicode. I don't know if you want to tackle that right now or not.

Originally posted by @rbtcollins in https://github.com/rust-lang/rustup/pull/2387/threads/MDIzOlB1bGxSZXF1ZXN0UmV2aWV3VGhyZWFkMjgyNjc4MTE0OnYy/unresolve

Rustup uses several instances of lossy UTF-8 conversion when handling the shell scripts it interacts with (for modifying $PATH, mostly). As of #2387, these instances will become errors instead for the most part. This should ideally be handled more correctly and the raw bytes should be manipulated instead (preferring simpler UTF-8 manipulations first where possible, of course).

Trace rustup's shell-script handling and lossy UTF-8 conversions, starting with cargo_home()?.join("bin").to_str() and the env-file path described in the issue. Review the related changes in #2387. Done means shell-script and PATH manipulation preserves raw bytes where needed and does not write bogus content when cargo_home is not valid Unicode.