Use `metamaskbot` to guide users in making release PRs

Creating release PRs is complex and difficult:

- There is always a risk that a change to a package is not captured in the changelog, but the risk is greater the longer that a release PR is open. Because release PRs are cut against `main`, it is possible for a commit to slip into `main` while the PR is open that does not get captured in the changelog before the PR is merged.
- There are rules that often go missed for how versions should get bumped based on the type of changes made (for instance, if a peer dependency is bumped in a package, then the major version of that package should be bumped).
- There are also rules that often go missed for which packages should be grouped together. For instance, if the peer dependency of a package is bumped, then that peer dependency should also be released.
- It is possible for developers to bump versions of packages they want to release but then forget to bump the root package.
- It is possible for developers to create a release PR but then fail to name it correctly.

We should have checks to look for these cases, and we should also have `metamaskbot` guide users along the way.

Start by locating the existing release PR workflow and the `metamaskbot` entry points. Review how release PRs are currently created, then define checks and guidance for changelog capture, version bumps, package grouping, root-package updates, and PR naming.

Written by the indexing model from the issue text.