fix(manifest): added dev-dependencies to Manifest

[JadKHaddad]

A project like this

[package]
name = "test-project"
version = "0.1.0"
edition = "2018"

[lib]

[features]
default = []

test-feature = ["dep:tracing"]

[dev-dependencies]
macrotest = { path = "../" }
tracing = { version = "0.1.40" }

[dependencies]
tracing = { version = "0.1.40", default-features = false, optional = true }

where the same dependency is defined twice, as optional and as not optional, and there is a feature that requires this dependency, macrotest will fail with the following error:

Caused by:
  feature `test-feature` includes `dep:tracing`, but `tracing` is not an optional dependency
  A non-optional dependency of the same name is defined; consider adding `optional = true` to its definition.

This PR adds dev-dependencies to the manifest and extends the manifest.dev_dependencies instead of the manifest.dependencies with the source_manifest.dev_dependencies, which was causing the dependencies to be overridden by the dev-dependencies.

[taiki-e]

Thanks for the PR. The code to be expanded is treated as a bin crate, so I guess this breaks cases that using dev-dependencies in the code to be expanded.

[JadKHaddad]

@taiki-e So dev-dependencies should be merged with dependencies under dependencies in the bin crate? The dependencies: BTreeMap in the manifest is overriding the keys, so dev-dependencies meta will override dependencies meta. Would it make sense to change the order the manifest.dependencies are extended? dev-dependencies then dependencies, so that dependencies override the dev ones? Since cargo features may only enable optional dependencies and no dev-dependencies, as far as i am concerned.

[taiki-e]

So dev-dependencies should be merged with dependencies under dependencies in the bin crate?

Yes, but dev-dependencies should win, similar to the way dev-dependencies are handled in normal tests, because “we do not enable it as a library dependency by default, but we always use it in our tests” is a common case.

The (non-exhaustive) rules when there is a conflict with normal dependencies should probably be found in something like the following

• Merge the features fields of the normal dependency and the dev-dependency.
• Retain the no-default-features field only if both have no-default-features, otherwise remove it.
• If the normal dependency is an optional dependency, make it non-optional and find a reference to it in the list of features in [features] table and remove it.