Make cargo-platform optional

[Jake-Shadle]

This makes cargo-platform optional.

When deserializing, the original string is completely lost which can be problematic if the original string is desired, rather than the "prettified" version, and also means that an additional heap allocation is required if using a different cfg parser like https://crates.io/crates/cfg-expr.

I've added it as the platform feature and made it non-default so that users need to opt-in if they still want to use cargo-platform, rather than making it default and then needing every crate that doesn't use it to require an opt-out.

[taiki-e]

I believe this has the same issue as #194.

[oli-obk]

Doesn't the cargo-platform crate allow you to re-create the string (worst case serializing it will give it to you)?

If not, I think this should be pursued upstream. I would also not worry about a few extra allocations, as we already got a billion allocations all over the place. cargo-metadata should never be on a hot path where that would be noticeable

[Jake-Shadle]

It does, but it loses the original information and can't give back the exact string, eg. cfg(target_os=\"linux\") will give back cfg(target_os = "linux") which makes it extremely annoying if you are trying to map a cargo_metadata target to the original span in the cargo manifest for the package. But yah, this would have similar issues to #194 so I'll just close this.

[Jake-Shadle]

Actually just found this doesn't matter at all, cargo metadata itself prettifies the cfg expressions before emitting the json so there is no way to directly map regardless.