Allow disabling default workspace discovery

[GeorgeTaveras1231]

From working with NX in a relatively complex yarn berry monorepo, I've found myself fighting with NX to get it to work properly.

NX assumes there is a circular dependency in cases where there isn't. NX does not take into account yarn's resolution algorithm and solely looks at the package names - so it gets an inaccurate representation of the project graph. In our case, we have workspaces that install a "cached" instance of a workspace - a strategy we adopted to prevent circular dependencies in cases where our packages have a loose circular dependency - split by the different lifecycles/environments of the project. Essentially, we may use a package to centralize build scripts, which uses a runtime library (a separate package), which is compiled by the same build scripts package -- in this case, we compile the runtime library, cache it, and use it in the build-scripts package. In the package.json of the build-scripts package, we refer to the package via a local path:

{
  "name": "build-scripts",
  "dependencies": {
    "runtime-lib": "./cached-workspaces/runtime-lib"
  }
}

And in the runtime lib

{
  "name": "runtime-lib",
  "scripts": {
    "build": "execute-build-scripts"
  }, 
  "devDependencies": {
    "build-scripts": "workspace:^"
  }
}

There are other cases where it improperly assumes a project dependency exists, for example, in the case where an older version of the workspace is installed - we do this in our repo by setting enableTransparentWorkspaces: false in our yarnrc and distinguishing between the workspace: protocol and a normal version range. When we do this, the dependency should be treated like a normal "external" dependency, not a project dependency.

Lastly, NX seems to not play well with monorepos that manage packages with multiple npm scopes. Having multiple npm scopes should be supported - otherwise, any project that is large enough that needs to migrate to a new npm scope is required to create a new monorepo or migrate all packages all at once, something that is not feasible for us.

Issue with multiple scopes: What I've noticed - though I can't say I know exactly what the problem is, is that NX does not properly register cross project dependencies when they have different scopes.

Proposal

NX should minimize decisions it makes about the graph, and allow consumers to opt into different graph discovery algorithms (maybe via plugins). Ultimately, I would like that NX stops trying to figure out the relationship between projects, and allow me to create a plugin where I can handle the details without fighting with its default settings. Long term, it would be good for NX to have a better integration with package managers such as yarn, in which case I wouldn't need to write my own plugin, but in any case, my original ideal will scale better because it will allow devs in the userland to develop plugins that integrate closely with new package managers as they arise - or extend existing plugins with new package manager features as they are released, without waiting for the NX devs to get to it.