link target metadeps not saved in legacy shrinkwrap dependencies properly

[isaacs]

Given a folder structure like this:

.
├── node_modules
│  └── a -> ../once
├── once
│  ├── node_modules
│  │  └── wrappy
│  │     └── package.json
│  └── package.json
├── package-lock.json
└── package.json

npm v6 produces a shrinkwrap like this:

{
  "requires": true,
  "lockfileVersion": 1,
  "dependencies": {
    "a": {
      "version": "file:once",
      "requires": {
        "wrappy": "1"
      },
      "dependencies": {
        "wrappy": {
          "version": "1.0.2",
          "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
          "integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8="
        }
      }
    }
  }
}

But arborist is doing this in the legacy shrinkwrap section:

{
  "dependencies": {
    "a": {
      "version": "file:once"
    },
    "once": {
      "dependencies": {
        "wrappy": {
          "version": "1.0.2",
          "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
          "integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8="
        }
      }
    }
  }
}

That's wrong.

It seems like the thing to do here is start from the root Node object, and walk the children (using target.children for links) and build the object that way.

The Shrinkwrap class needs to keep a reference to the tree representing its root node (replacing if we ever give it a new node at the '' location), and should have a Map of location -> metadata. If there are nodes that don't end up being actualized, we can still write back the metadata for those locations. (So, for example, a reify() that omits dev deps will still have them in the lockfile). Then we can also trivially write the yarn.lock on save(), solving #82.

The reason why it didn't do this initially was a notion that Shrinkwrap and Node should be separate concerns, and shouldn't know too much about each other. However, in practice, they're all up in each other business anyway, and we're doing a lot of translating path strings into object paths and so on. Since the two classes really can't live apart from one another, we may as well have a more straightforward way of having them interact.