Implement allow-workspace for deny-by-default projects

[nickpdemarco]

Add workspace-aware deny-by-default policy support

Problem

Organizations wanting to implement strict dependency policies face a challenge with cargo-deny's current design. When using a deny-by-default approach (deny = [{ name = "*" }]), workspace crates get blocked along with external dependencies, making it impossible to implement the common policy of "deny all external dependencies but allow our own workspace crates."

This forces teams into awkward workarounds, including:

• Dynamically modifying deny.toml files with sed/awk scripts to inject workspace crate names
• Using fragile CI pipelines that extract crate names and update configuration files

Solution

This PR adds an allow-workspace configuration option to the [bans] section that automatically allows all workspace members when enabled, even when using deny-by-default policies.

[bans]
# Deny all external dependencies by default
deny = [{ name = "*" }]

# Automatically allow workspace members
allow-workspace = true

# Explicitly allow blessed external dependencies
allow = [
    { name = "serde", version = "1.0" },
    { name = "tokio", version = "1.0" },
]

How it works

When allow-workspace = true:

• All workspace members are automatically treated as allowed, regardless of deny rules
• Workspace members take precedence over explicit deny entries
• External dependencies still require explicit allowlisting
• Works seamlessly with both single-crate and multi-crate workspaces
• No diagnostics are emitted for workspace members (they're silently allowed)