cargo: parse dev_dependencies and build_dependencies

[bonzini]

Dev-dependencies are used by tests. Even before test or example sections of Cargo.toml are parsed, it can be useful to support them in the dependencies method; probably there should be a dev_dependencies argument to workspace defaulting to true but changed to false by subprojects.

Processing build dependencies is needed for code generators that need to use native: true. Without them, Meson does not know that the code generators' own dependencies must be configured with native: true. The plan is that if a package appears in either:

• [build-dependencies] and default_members -> then configure it for both machines
• [build-dependencies] or any [target.cfg().build-dependencies] + the extra_members keyword argument -> then configure it for the build machine.

This matches Cargo: there is no way to place a package in default-members yet build it only for the host; a selected member is always built for the requested target.

Configuring a member that should never be built by Cargo to build for the build machine can be done with a dummy entry:

[target.cfg(any()).build-dependencies]
member = { version = "=VER", path = "..." }

Once artifact dependencies (-Z bindeps) are stabilized, this could be written also as

[build-dependencies]
member = { path = "...", artifact = "bin" }