chore: update docs/contributing.md with yarn constraints --fix (#4318)

## Explanation
@Gudahtt
[wrote](https://consensys.slack.com/archives/C01V1L10W2E/p1715878493772209?thread_ts=1715869562.944709&cid=C01V1L10W2E):
> there is a missing step, you should run yarn constraints --fix and
yarn to update package versions across the repository, and then to
update the lockfile.
>
> Unfortunately I don't think this step is documented at the moment. It
was an unanticipated consequence of some recent-ish changes to the
release tool and to how the monorepo is structured. We have plans to
automate this step as well.

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to? Are there other
links that reviewers should consult to understand these changes better?

For example:

* Fixes #12345
* Related to #67890
-->

## Changelog

<!--
If you're making any consumer-facing changes, list those changes here as
if you were updating a changelog, using the template below as a guide.

(CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or
FIXED. For security-related issues, follow the Security Advisory
process.)

Please take care to name the exact pieces of the API you've added or
changed (e.g. types, interfaces, functions, or methods).

If there are any breaking changes, make sure to offer a solution for
consumers to follow once they upgrade to the changes.

Finally, if you're only making changes to development scripts or tests,
you may replace the template below with "None".
-->

## Checklist

- [ ] I've updated the test suite for new or updated code as appropriate
- [ ] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [ ] I've highlighted breaking changes using the "BREAKING" category
above as appropriate

Author: dbrans

docs/contributing.md

@@ -209,7 +209,11 @@ The [`create-release-branch`](https://github.com/MetaMask/create-release-branch)
 
       Once you save and close the release spec, the tool will proceed.
 
-2. **Review and update changelogs for relevant packages.**
+2. **update all packages dependencies to their latest version**
+
+   Run `yarn constraints --fix && yarn && yarn dedupe`.
+
+3. **Review and update changelogs for relevant packages.**
 
    1. At this point, the versions of all packages you intend to release have been bumped and their changelogs list new changes. Now you need to go through each changelog and make sure that they follow existing standards:
 
@@ -220,19 +224,19 @@ The [`create-release-branch`](https://github.com/MetaMask/create-release-branch)
 
    2. Run `yarn changelog:validate` to ensure all changelogs are correctly formatted.
 
-3. **Push and submit a pull request for the release branch so that it can be reviewed and tested.**
+4. **Push and submit a pull request for the release branch so that it can be reviewed and tested.**
 
    Make sure the title of the pull request follows the pattern "Release \<new version\>".
 
    If changes are made to the base branch, the release branch will need to be updated with these changes and review/QA will need to restart again. As such, it's probably best to avoid merging other PRs into the base branch while review is underway.
 
-4. **"Squash & Merge" the release.**
+5. **"Squash & Merge" the release.**
 
    This step triggers the [`publish-release` GitHub action](https://github.com/MetaMask/action-publish-release) workflow to tag the final release commit and publish the release on GitHub.
 
    Pay attention to the box you see when you press the green button and ensure that the final name of the commit follows the pattern "Release \<new version\>".
 
-5. **Publish the release on NPM.**
+6. **Publish the release on NPM.**
 
    The `publish-release` GitHub Action workflow runs the `publish-npm` job, which publishes relevant packages to NPM. It requires approval from the [`npm-publishers`](https://github.com/orgs/MetaMask/teams/npm-publishers) team to complete. If you're not on the team, ask a member to approve it for you; otherwise, approve the job.