The --target flag does not seem to respect target-conditional features in generated SBOM.

We have some library crates that make use of target specific feature enablement. For example:

```
[target.'cfg(all(target_os = "linux", target_env = "musl"))'.dependencies]
jsonwebtoken = { workspace = true, features = ["aws_lc_rs"] }

[target.'cfg(not(all(target_os = "linux", target_env = "musl")))'.dependencies]
jsonwebtoken = { workspace = true, features = ["rust_crypto"] }
```

A crate with the above Cargo.toml would then be consumed in an application that we'd generate an SBOM for. Note that we do not have features in the application.

With this, my expectation would be that when I run `cargo cyclonedx --target x86_64-unknown-linux-musl`, the generated SBOM would not contain `rust_crypto` or any dependencies of `rust_crypto`. Unfortunately it seems that when the SBOM is generates, it contains the dependencies from both the features.

Is there any the SBOM can be generated for the specific target with the correct feature set based on the target?

Start by reproducing the issue with the target-conditioned dependencies shown in Cargo.toml and run cargo cyclonedx --target x86_64-unknown-linux-musl. Compare the generated SBOM with the target-specific feature resolution; done means the musl SBOM excludes rust_crypto and its dependencies while retaining the correct feature set.

Written by the indexing model from the issue text.