chore(deps): remove unneeded Yarn resolutions

[agilgur5]

Motivation

• removing these has no impact on resolution, as can be seen in the yarn.lock
  • any bumps in these deps will produce either the same minor or same major version (most are same minor version) -- i.e. no breaking changes
  • basically, these are extraneous as of this time

Related to #11630, which removes unused deps; this removes unneeded resolutions

Modifications

• remove resolutions for @types/react, autolinker, fast-json-patch, lodash, and prismjs

• did not touch semver or react-toastify

  • the semver resolution currently forces all versions to the same as the resolution (including different majors, which can be seen in the yarn.lock)
  • the react-toastify resolution was needed for fix: upgrade argo-ui components to latest #11585 and it is removed as part of build upgrades in build(ui): upgrade to Webpack v5 + upgrade loaders + plugins #11628
    • EDIT: rebased on top so this is no longer present

Verification

Install succeeds, build passes.
Spot check on render.

[terrytangyuan]

I remember these resolutions were added to resolve security issues.

[agilgur5]

Per the first line of the PR, removing these has no impact on resolution. I imagine that those resolutions are either outdated or were used incorrectly to update a version in yarn.lock. Looking at #10842, that was indeed used to update a version in yarn.lock.

yarn.lock can just be updated directly/independently if the bump is within the SemVer range; it does not need a resolution. Can just run yarn install after and it will update your node_modules to match the new lockfile (and make any other auto-updates or throw an error if there's an issue). yarn upgrade can also be used to similar effect, though you often have to specify a version (or range or tag).
You will need to comment out the --frozen-lockfile flag temporarily in the .yarnrc though. Normally that flag is only set in CI and not during development (it was made as a default here, seemingly so that it doesn't have to be individually set in multiple CI builds?)

[terrytangyuan]

We can merge and see if Snyk check passes

[agilgur5]

It did 😉 .
This is basically a no-op as all the versions in the yarn.lock don't change.