Logging bumped internal dependencies for packages included in a release is painful to do manually and is often forgotten

This is an offshoot of #90.

When a new `core` release is created, we want consumers to be aware of any bumps to dependencies that occur in new versions of packages being included in that release. To do this, we ask that changelog entries be added for these dependency bumps.

At the same time, the `core` monorepo contains a Yarn constraint which enforces that when a workspace package is bumped, for every package which depends on that package, the version range for the dependency listed in that package's manifest must match the new version. Because release PRs involve bumping versions of packages within the monorepo, they are guaranteed to also contain dependency bumps for those packages. For instance, if `@metamask/base-controller` is bumped to `2.3.4`, then any controller which depends on this package _will_ be updated to use a version range of `^2.3.4` (it has to be).

When it comes to dependency bumps for packages that live outside of the monorepo — e.g. `@metamask/rpc-errors` — the author of a release PR is given a reminder to include any bumps related to those packages in changelogs. Because those bumps will have already occurred in commits prior to the release PR, `create-release-branch` (thanks to `auto-changelog`) will automatically pick up those commits and add them to the changelogs when it creates the release branch.

However, _internal_ dependency bumps are another story. The command that adds them is `yarn constraints --fix`, which `create-release-branch` runs after creating the release branch; but because this does not occur within a prior commit, `auto-changelog` cannot see the bumps.

The result of this is the author of a release PR must check for and add these types of entries manually. This is not an obvious step, and more often than not, it is forgotten and these bumps go unlogged. We should prevent this from happening.

## Acceptance Criteria

- For each package-to-be-released, `create-release-branch` offers a way to detect bumps to dependencies that have occurred within the package and produce an error if those bumps are not reflected in changelog entries that correspond to the version-to-be-released for that package.
- This check is added to the `lint` package script so that it can be run after creating a release branch to verify the changelog.
- This check is also run in CI, so that the author is compelled to add missing entries if they don't exist. (This may happen naturally in the previous step.)
- Optionally, `create-release-branch` offers a way to take a PR number that corresponds to the release branch and automatically add these changelog entries, saving time when creating a large release PR.

---

> **(Previous suggestion, preserved for posterity:)**
>
> We should consider adding a `validate` subcommand/flag to `create-release-branch` which would detect these kinds of dependency bumps relative to the latest release of the package that has them and ensure that entries are present in the package's changelog. We could even add a `--fix` flag which would automatically add the bumps.
>
> I realize that this means that `create-release-branch` would no longer solely create a branch, it would also manage that branch, but perhaps we could rename the package at a later point in time.

Start by locating the create-release-branch command and the package lint script, then inspect how release branches, changelogs, and CI are currently handled. Define the dependency-bump validation flow against the stated acceptance criteria, including how missing changelog entries are reported and optionally generated. Done means the check is available through lint and runs in CI for release changes.

Written by the indexing model from the issue text.