Fix "expected workspace package to exist" errors

[schmod]

Summary

Currently, some workspace projects will produce incorrect installs or errors when commands like yarn add or yarn upgrade-interactive are run from within a workspace where the workspace root the workspace have conflicting transitive dependencies.

Currently, running yarn add from within a workspace will hoist all of that workspace's dependencies into the root's node_modules directory, replacing the root's own dependencies. A subsequent yarn install eventually yields the correct node_modules hierarchy.

Additionally, a behavior introduced in #7289 turns this scenario into a fatal error when the conflicting package is a devDependency.

It appears that these issues occur because the package-hoister isn't considering the workspace root's dependencies when yarn add (or another command) is run from a directory that is not the package root. (yarn install is a special-case that always assumes that workspaceRootIsCwd to true)

Test plan

I've been using the repo that @smably created while troubleshooting #7807 to test this patch.

Here's how I tested:

1. Clone repo
2. Remove .yarnrc and link in a locally-built Yarn executable
3. Run yarn install
4. Remove node_modules from .gitignore and stage or check-in the installed packages
5. cd project-a and run yarn add left-pad – without the patch in this PR, this command will fail with an error: expected workspace package to exist for "pretty-quick".

Another variation:

1. Clone repo
2. Remove .yarnrc and link in a locally-built Yarn executable
3. Edit package.json and project-a/package.json to move all devDependencies to dependencies.
4. Run yarn install
5. Remove node_modules from .gitignore and stage or check-in the installed packages
6. cd project-a and run yarn add left-pad – without the patch in this PR, this command will produce an incorrect node_modules hierarchy. (Running yarn again, however, fixes things)

---

The current master branch's test-suite doesn't appear to run on my machine at all. I could use some assistance formalizing the test-scenario into a proper unit-test. (Specifically, I also couldn't figure out how to write a test for this scenario that doesn't use the live registry)

Also, frustratingly, I can't figure out a more minimal reproduction scenario than the one that @smably came up with. I wish I better understood the behavior that's at the root of this bug.

Fixes #7734
Fixes #7807

[schmod]

I've tweaked the patch slightly, and it appears that the remaining test failures are unrelated to this PR.

[schmod]

Closing this, as Yarn 1 appears to be unmaintained.