allow `Cargo.toml` pkg metadata as config source

[Emilgardis]

Ideally I would like to get rid of Cross.toml eventually and use package.metadata.cross in Cargo.toml to store cross configuration.

Originally posted by @reitermarkus in #624 (comment)

[Emilgardis]

This would be a good opportunity to switch to a serde deserialize implementation of getting configs

[reitermarkus]

To get the config, we can use https://docs.rs/cargo/0.60.0/cargo/util/config/struct.Config.html.

We'll just need to parse some more arguments to get all information for calling https://docs.rs/cargo/0.60.0/cargo/util/config/struct.Config.html#method.configure.

[Emilgardis]

the cargo lib is quite heavy, not sure it's worth it

[mntns]

I just submitted a PR for using serde to deserialize the Cross.toml and would be happy to integrate the Cargo.toml as config source if it gets merged.

[Emilgardis]

Should it be valid to have configuration in both Cross.toml and Cargo.toml? I think not.

If we do allow it, should we panic when a value exists twice?

[mntns]

I just submitted a PR for that feature. For now, a warning will be shown if there are a Cross.toml and configuration values in the Cargo.toml at the same time, making the two configuration sources mutually exclusive.

Should the Cargo.toml method be the primary form of configuration? That could then be reflected more explicitly in the documentation.

[Alexhuszagh]

Should the Cargo.toml method be the primary form of configuration? That could then be reflected more explicitly in the documentation.

I think so, our goal was to phase out Cross.toml I believe (which wouldn't be anytime soon), so first having Cargo.toml be the primary form of configiration, then warning about Cross.tomlif it exists a few releases later would be good.