Replace cargo with cargo_metadata

[gibix]

cargo should be replaced with cargo-metadata.

[cardoe]

I'd like to get some rationale behind that. I've got a few issues with that:

• Its a third-party crate and not a first-party crate (e.g. not developed by the Rust Lang project directly) for working with a first-party package system
• In the past cargo-metadata was slow to update and reflect new features.
• What happens when Cargo defines a new metadata output version? Its already warning recently that you need to specify the version. It will take some time for cargo-metadata to be updated and the API will be overhauled. In turn we'll have to wait for the main Cargo project to update and then for cargo-metadata to update. Instead the current approach allows us to upgrade to a newer Cargo when its released and we need the features.

[gibix]

• It's a third-party crate, but cargo metadata supports explicit versioning
• When will be new features will be easier to push a single PR to cargo_metadata than menage a lot of boilerplate code in cargo-{ebuild,bitbake,dep,...}
• When a new cargo metadata api version will be available the old one will remain for the time needed by cargo_metadata and similar projects to adapt. There will be no breaking changes from the cargo side.
• At now the cargo-ebuild's cargo is 6 version behind the last stable release. There are some breaking changes in the apis that I fixed in misc changes #7 but this problem will be present again in the feature and I think that rely on cargo api itself requires more maintanance that cargo_metadata.

[gibix]

Now cargo_metadata has support for deserialize custom package metadata field into struct: oli-obk/cargo_metadata@2137d30

[cardoe]

Unfortunately cargo_metadata has dropped a number of fields we use for Gentoo ebuilds with newer versions so I'd still need to use cargo to get all the data.