Fix handling of non-UTF8 sequences in path rewrites

[hdoordt]

Addresses comments (1 and 2) in #28

[hdoordt]

@LukeMathWalker Re this comment on #28

Supporting workspaces that are located at paths containing non-UTF-8 segments is going to require some rethinking. The problem with the implementation in this PR is that it rewrites the dependency paths to absolute paths, which may contain such segments, and stores them in the cargo_manifest::Manifest which of course does not support non-UTF-8 strings for paths. The absolute paths are there so as to be able to tell whether packages are including from the same path. We can avoid using absolute paths if we come up with some other means of figuring out whether two packages include from the same path relative to the workspace root.

However, the current implementation uses cargo_metadata to determine the workspace root, which tries to parse the absolute path of the workspace root as UTF-8 (See code), and therefore the application as a whole will fail if the workspace lives in a path containing non-UTF-8 segments.

I think the best course of action here is to panic when rewrite_dep_paths_as_absolute yields a path with non-UTF-8 segments, as that case should be unreachable.

[LukeMathWalker]

OK, let's keep it simple for now.

[cbgbt]

Sorry for the churn here -- I mentally noted that to_string_lossy() was probably not a great idea when I wrote it, but forgot to circle back and think on it some more. I should have come up with a more thoughtful solution before submitting the PR.

I agree with @hdoordt, this seems like a good solution to me!

[hdoordt]

@cbgbt Don't feel bad, as a reviewer, I should have caught this one.
@LukeMathWalker Can I interpret your "OK, let's keep it simple for now." as an approval of this PR?