fix(ls): correctly show deduped dependencies

[milaninfy]

Attempt to fix npm ls output

Problem:

• deduped nodes are cloned when encountered using previously seen nodes set but they are not explored further when we are requesting npm ls dep-name if dep-name is a child of some deduped parent then whole tree would be shown till that parent but logically dep-name is still the child/grand-child of that.
• When deduped nodes are explored further it results in cycle when dep1 is ancestor of dep2 which again depends on dep1 creating a cycle when explored, also the algorithm used is BFS so it's hard to detect cycle.

Solution:

• Use DFS like approach with custom cycle detection checks.
  • keep track of how any node is discovered. so each node or parent node will have a list containing all the relevant visited nodes, we check if current node is in that list then it's a cycle and we don't need to explore this node.
• This solution attempts to explore cloned nodes of deduped nodes and use cached result so that it fixes the output and perform better. since those nodes are deduped and already explored we can use the result.

Progress:

• still some cases which might result in Infinite loop and need to discovered those.
• very slow and uses very large memory during run when ran on big repo, need to find out optimizations or better approach
• Fix/add the test cases
• Refactor

Test output

`npm ls child` - before and after

~/workarea/rep/repro $ npm ls child
repro@1.0.0 /Users/milaninfy/workarea/rep/repro
└─┬ relative-p2@1.0.0
  └─┬ grand-p1@1.0.0
    └─┬ parent-p1@1.0.0
      └── child@1.0.0

~/workarea/rep/repro $ lnpm ls child
repro@1.0.0 /Users/milaninfy/workarea/rep/repro
├─┬ relative-p1@1.0.0
│ └─┬ family@1.0.0
│   └─┬ grand-p1@1.0.0
│     └─┬ parent-p1@1.0.0
│       └── child@1.0.0
└─┬ relative-p2@1.0.0
  └─┬ grand-p1@1.0.0 deduped
    └─┬ parent-p1@1.0.0 deduped
      └── child@1.0.0 deduped

fixes: #7917

[wraithgar]

Passing in function like this and visit can be pretty confusing when trying to understand the code later. It's also easy to introduce unintended mistakes cause state can get pretty noodly.

Let's call these beforehand and pass the results as new params.

[wraithgar]

The reason workspacesEnabled is pulling from flatoptions is because it's derived from workspaces config. includeWorkspaceRoot has no such distinction so we should pull it from config like the rest of this command does.

We know this is less than ideal, but fixing this disparity is a future concern.