chore: resolutions and dependencies cleanup, address CVEs

[tomkdgun]

Description

There are many leftover resolutions/overrides from past fixes that are no longer relevant and necessary after recent changes.
We need to attempt to remove as many manual resolutions as possible to clean up our dependencies.
Some of them are bringing in modules that are no longer in the dependency tree, override newer versions by older or are not aligned with OpenSearch Dashboard 3.8.0 dependencies.
In some cases resolutions were used instead of dependencies/devDependencies, or completely assume that some specific dependencies will be provided by OpenSearch Dashboard.

Changes:

• Cleaning up resolutions/dependencies/devDependencies
• Align with versions used on OpenSearch Dashboard 3.8
• Check CVEs by yarn audit and address these possible to fix

Testing:

• yarn osd bootstrap with OpenSearch Dashboard 3.8
• yarn build
• yarn test:jest

Details:

• The npm modules which require uuid 8.x, 9.x or 10.x will work with 11.1.1 without code changes, but setting uuid 14.x in resolutions it's a risk, this is why I've provided a change from 14.x to 11.1.1 as we have on OpenSearch Dashboard
• Adjusted jest setup to handle recently updated elastic/charts in OpenSearch Dashboard 3.8.0 and handle ESM dependencies correctly e.g. uuid

Issues Resolved

[List any issues this PR will resolve]

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[lezzago]

Risk: removing resolutions entries can silently reintroduce CVEs

This PR drops ~25 resolutions overrides from package.json. Those entries were pinning patched transitive versions (e.g. form-data, tough-cookie, braces, micromatch, cross-spawn, semver, minimatch, glob-parent, loader-utils, terser, d3-color).

The committed yarn.lock currently still resolves these to safe versions (verified: d3-color 3.1.0, form-data 4.0.6, tough-cookie 5.1.2, cross-spawn 7.0.6), so the change is safe today — the lockfile is doing the pinning.

The concern is durability: with the overrides gone, there is no longer a guard preventing a vulnerable version from coming back. A future yarn install / lockfile regeneration, or an upstream transitive dependency bump, can silently pull a vulnerable version back in with nothing to stop it.

Suggestion: either keep the security-motivated resolutions for the CVE-relevant packages, or confirm the team is intentionally relying on the committed yarn.lock alone (plus CI/Dependabot/audit gating) for CVE remediation going forward.

[tomkdgun]

@lezzago My understanding is that yarn.lock + yarn audit should be used in typical cases to address CVEs. Also in many cases CVE should be fixed on OpenSearch Dashboard side, not on plugin.
The resolutions should be used only when regular update of dependency is not possible and some override is need it, e.g. some module has strict version "1.2.3" or "~1.2.3" but we need >= "1.3.0". Also resolutions should be frequently cleaned up when are not required, e.g. to not cause situation that module requires "^2.0.0" but we have "1.2.3" in resolutions (incompatible version)