Fix Windows CRLF Issue

[timbess]

Cargo configs are injected as a literal string which, on Windows, can end up with escaped CRLF line endings in cargo-bazel.json causing the digests to be different on Linux/Windows. This PR parses the inner string literal to prevent platform specific differences in the config.toml. There might be a better way to do this, but adding a new top level command to cargo-bazel to parse TOML into JSON felt wrong, and adding a second binary seems even worse. I'm open to solving this another way if ya'll have a better idea.

[google-cla[bot]]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[timbess]

@UebelAndre Not sure who to ask about this, are there any changes required to get this merged? I'm just checking back in so we can hopefully delete our patch soon.

[timbess]

@UebelAndre

Previously the cargo config was stored as a Value::String(... literal file contents). Parsing the inner String into a Value removes the platform specific line endings which caused Windows/Unix to have diverging digests. It would probably be cleaner to parse the TOML into JSON earlier on, but that's done in Starlark so it was a lot easier to handle this in Rust while parsing the config. I'm open to suggestions for better alternatives, but this does fix the issue on our Windows build.