feat: frogbot support for yarn workspaces

[sean-perkins]

• All tests passed. If this feature is not already covered by the tests, I added new tests.
• This pull request is on the dev branch.
• I used gofmt for formatting the code before submitting the pull request.
• Update documentation about new features / new supported technologies

---

Relates to #798

Frogbot fails to apply dependency fixes in Yarn workspace (monorepo) projects. When a vulnerability is detected in a workspace package the fix command is run from the workspace package's subdirectory, but yarn upgrade/yarn up must be run from the workspace root against a specific workspace. This PR adds workspace detection.

A secondary bug is also fixed: isYarnV1Project previously ran the global yarn --version binary to determine the project's Yarn version. Projects using Yarn Berry ship their own binary via .yarnrc.yml yarnPath, so the global version could be wrong. The new implementation reads the version directly from the yarnPath filename in .yarnrc.yml, which is faster and version-agnostic.

[eranturgeman]

Hello @sean-perkins and thank you for your contribution!
Unfortunately we cannot approve this PR for the following reasons:

1. V2 (dev) is currently a version on sunset and we do not accept any new features or improvements to it. We currently accept code contributions only to v3_er (soon to be the new 'main'). Im working on updating the docs in frogbot repo to reflect that
2. You successfully updated the packaghandler, but there are several missing parts that are needed to accompany this step (this is only the last step in adding a real support to workspaces) - we must adjust our project structure detection mechanism which in its old version (the one V2 uses) does not support it. And we must adjust the process we do the fixes in general - since we are using yarn commands to update dependencies without real support to a workspace we might accidentally updating a version of a package in one manifest, but downgrading it in another.
3. The tests you provided, although well written, are covering only few of real world use cases where we have to handle huge mono-repos, projects that combine yarn and npm altogether and we must separate the fixes between them and make sure we correctly identify the actual technology (which we cannot in v2 that is based on manifests rather than lock files)
4. I will raise this as a feature request to our Product Managers to see when we plan to fully support this structure (we already currently working on the infrastructure we need for this)