ci(github): add dependency version consistency check

[jagpreetsinghsasan]

Commit to be reviewed

ci(github): add dependency version consistency check

Primary Changes
---------------
1. Added a new custom check which checks if there are any inconsistency with the dependency version, which is already being used with an exsisting package.

Changes needed to incorporate 1)
-------------------------------
2. Added a new dependency in the root package.json
3. Added a new npm script in the root package.json
4. Updated the lock file for the dependency inclusion

Fixes #3612

Pull Request Requirements

• Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners
For rebasing and squashing, here's a must read guide for beginners.

[jagpreetsinghsasan]

@petermetz I have created multiple tickets to address the fix for this (#3684 till #3698)

[petermetz]

@jagpreetsinghsasan Almost perfect, just please add the currently bad dependencies to the ignore list so that when we merge this PR the custom checks are passing.
Then we can remove the ignore declarations as we fix the problems chunk by chunk and finally (hopefully) end up with no ignores at all.

[jagpreetsinghsasan]

@jagpreetsinghsasan Almost perfect, just please add the currently bad dependencies to the ignore list so that when we merge this PR the custom checks are passing. Then we can remove the ignore declarations as we fix the problems chunk by chunk and finally (hopefully) end up with no ignores at all.

@petermetz shall I add the ignore list with packages in it (instead of dependencies)? This is because the way we are targetting a fix for this on per-package basis. A single dependency mismatch can happen in multiple packages and so tracking the ignore list (if it is per-dependency basis) will be much harder against the resolved issue (the 14 phases of addressing the fix for this)

[petermetz]

@jagpreetsinghsasan Yes, that works as well, in this regard, I'm OK with whatever is more convenient because eventually we'll empty out the list either way. Thank you!