If the shrinkwrap code calls `getRequested` on an optional dependency,
the `spec` passed to `npa.resolve` is null. `npa.resolve` then thinks
it's a request `fromRegistry`, with spec defaulting to `latest`. And
in case the real spec is a tarball, returns nonsensical result where
`isRegistry` is true, `fetchSpec` is `1.0.0` instead of `file:...` and
the record written to the shrinkwrap is wrong. It contains a `resolved`
field, which should be used only for packages downloaded from the registry.

The path in `sw.requires` is always relative to the requesting package
location, and the default from `packageRelativePath(tree)` is always correct.

For `type=file` dependencies, `tree.package._where` contains the `realpath`
of the requesting tarball, which is the location where it was unpacked in
`node_modules`. That's completely useless for resolving dependency paths.
We're interested in the source location of the packed tarball. That's the path
against which the dependency spec should be resolved.

When comparing specs like `file:../b-1.0.0.tgz`, the `rawSpec` and `saveSpec`
contain paths that are relative against different roots. We need to compare
the `fetchSpec`, too, which is absolute.

`realpath` contains the location of the unpacked tarball, and that's useless when
resolving relative dependency paths in `package.json`. For that resolution, the location
of the packed tarball is important.