feat: update intra-workspace dependency versions during release

[lukidoescode]

Problem

When running cargo changeset release in a workspace, the release operation only updates each package's own [package].version field. It does not update version specifications for intra-workspace dependencies — neither in individual crate manifests nor in the root workspace [workspace.dependencies] table.

Example

Given a workspace where crate-b is bumped from 0.1.0 to 0.2.0:

Before release:

# Root Cargo.toml
[workspace.dependencies]
crate-b = { path = "crates/crate-b", version = "0.1.0" }

After release:

# crates/crate-b/Cargo.toml
[package]
version = "0.2.0"  # ✓ Updated

# Root Cargo.toml
[workspace.dependencies]
crate-b = { path = "crates/crate-b", version = "0.1.0" }  # ✗ Not updated

The workspace dependency definition still references the old version, which causes an inconsistency between the published version and any downstream consumers that rely on the workspace-level version specifier.

The same problem applies to packages that declare an intra-workspace dependency with an explicit version:

# crates/crate-a/Cargo.toml
[dependencies]
crate-b = { path = "../crate-b", version = "0.1.0" }  # ✗ Not updated

Expected Behaviour

After a release, all version constraints that reference a released crate should be updated to the new version. Concretely:

1. [workspace.dependencies] — If an entry for a released crate exists, its version field must be updated to the new version.
2. Per-crate [dependencies] / [dev-dependencies] / [build-dependencies] — If a dependency entry references a released intra-workspace crate by path and/or explicit version, its version field must be updated.

Scope

• Only intra-workspace crates that are part of the current release (i.e., they appear in the planned releases for this run) need to be updated.
• The update must preserve existing TOML formatting and comments (consistent with the current use of toml_edit).
• The change should be covered by tests.