Option to create prerelease versions for a workspace dependency prerelease

My team often makes beta releases to test new features. We are currently developing in a Node monorepo that contains many libraries and plugin packages that often depend on each other, meaning that releasing a new version of one package will frequently mean releasing new versions of other packages too. At the moment, if we want to release a new prerelease version of one package, release-please will in turn create patch releases for all the packages in the monorepo that depend on it. This is undesired as these dependents will then be stable releases that depend on a beta version of the original package.

For example, say we have packages `foo` and `bar` in a workspace, where `bar` depends on `foo`. We want to test a new feature in `foo`, so we specify a beta version of it by using `Release-As` in the commit footer. release-please will now consider making a PR to release, say, `foo@1.5.0-beta.1`. The `node-workspace` plugin would then notice that `bar` depends on the updated `foo` package and bump the `bar` version from, say, `bar@1.2.0` to `bar@1.2.1`. `bar@1.2.1` would now depend on `foo@1.5.0-beta.1`. This means that a stable version of `bar` is now depending on a test version of `foo`. If there are any bugs we haven't yet caught in `foo`, they could be propagated to consumers of `bar`, as `bar@1.2.1` is within the same default caret range as `bar@1.2.0`!

Instead, it would be better to have release-please create prerelease versions of all the dependents, pinning the prerelease version of their dependency. So, if `foo@1.5.0-beta.1` is being considered, we should also create a `bar@1.2.0-beta.1` that depends on the new prerelease version of `foo`. It should also use the exact version of `foo` rather than a range so that we're sure that `bar` is using the correct version of `foo` for testing.

This change could be gated by a configuration option, though I'm not sure why anyone would want the previous behaviour (could it be considered a bug?) Ideally, it would also be able to handle creating a separate PR if `bar` also had some unrelated fixes committed, so that a PR to release those fixes is separated out from the PR to create a prerelease version of the dependency chain. We'd also need to be aware of what prerelease versions of `bar` had already been released so that we don't overwrite any. I'd expect we'd calculate the prerelease version of `bar` by appending the latest version with the prerelease string from `foo`, and increment the prerelease identifier to avoid duplicates.

Apologies if I've used inaccurate or imprecise terminology when describing this issue, feel free to ask for any clarifications!