Take dependencies into account when bumping versions

### Scenario

I have two packages in the workspace: `package-a@0.1.0` and `package-b@0.1.0`. `package-b` depends on `package-a` (i.e. `package-b@0.1.0` depends on `package-a@^0.1.0`).

Then, I make a breaking change **in `package-a`** and run this CLI.

#### Actual result

It makes a minor release of `package-a@0.2.0`. That's fine.

#### Expected result

It should *also* make a minor release of `package-b@0.2.0`, which would be dependent on `package-a@^0.2.0`.

Otherwise there is still `package-b@0.1.0` that relies on `package-a@^0.1.0`, which isn't compatible with `package-a@0.2.0`. Therefore, there is no chance to get `package-b` of version that depends on `package@0.2.0`, though technically it exists and must be published.

This would be consistent e.g. with `@changesets/cli` - [How dependencies are bumped](https://github.com/changesets/changesets/blob/main/docs/decisions.md#how-dependencies-are-bumped):

> For example, if I have two packages:
>
> `packageA` at `1.1.1`
>
> and `packageB` at `1.1.0` that depends on `packageA` at `^1.1.0`.
>
> If I add `packageA` to a changeset with a `major` change, the version of `packageB` within the mono-repo should also be updated. If it is not, either `packageB` in the mono-repo will not use `packageA` in development, or `packageB` in development will not match an installation of `packageB` in production.
>
> As such we end up with a changeset that includes `packageA` as `major` and `packageB` as `patch`.
>
> All updating of dependencies is done as a patch bump. If you want to indicate a more significant change to `packageB` from consuming a new version of `packageA`, we recommend adding a second changeset specifically for `packageB`.