Don't always prune mirrored scoped packages resolved by URLs

[bollwyvl]

Summary

With a .yarnrc configured for offline mirroring with yarn-offline-mirror-pruning, packages that are resolved in yarn.lock to registry URLs, such as:

"@jupyterlab/about-extension@^0.3.1":
  version "0.3.1"
  resolved "https://registry.yarnpkg.com/@jupyterlab/about-extension/-/about-extension-0.3.1.tgz#c8cbdab05d33341d9e644051c104edc0d8029314"

...will indeed be mirrored as @jupyterlab-about-extension-0.3.1.tgz. However, this will be immediately pruned, as the tarball expected on disk will be about-extension-0.3.1.tgz (derived from the URL) which won't match as it is is not suitably mangled.

This PR adds an extra expectedTarball for the pre-mangled version. I don't know if this is exactly the right approach, but local testing suggests it works, and since the expected-but-unfound tarballs aren't returned/checked, it didn't seem like it could hurt.

Test plan
This adds a new test case, with a copy of the existing mirror fixture, but with yarn-offline-mirror-pruning and a yarn.lock as I have been seeing in my testing, as opposed to the file-based one. It didn't seem appropriate to add this to the original test case, but I can be easily persuaded otherwise!

[bollwyvl]

Travis error:

FATAL ERROR: deserialize context Allocation failed - process out of memory

Appveyor error:

 FAIL  __tests__\commands\add.js (274.858s)
  ● modules resolved multiple times should save to mirror correctly
    Timeout - Async callback was not invoked within timeout specified by jasmine.DEFAULT_TIMEOUT_INTERVAL.
      
      at null._onTimeout (node_modules\jest-jasmine2\vendor\jasmine-2.5.2.js:1977:23)
      at Timer.listOnTimeout (timers.js:92:15)

The travis one seems spurious, but I'll look into the appveyor one!

[voxsim]

Could you please remove this comment?

[voxsim]

@bollwyvl thanks! :D Please give me some time to check the commits, if you need help, let me know, ok? :P

[voxsim]

@bollwyvl the PR looks great! @bestander could you please merge it?

[bollwyvl]

Hey, thanks! (and to you @bestander!) The hard work is really appreciated!

yarn has been really great to work with. A bit of context: we're looking at adopting yarn across https://github.com/jupyterlab/jupyterlab, as well as shipping maintainer tooling (for at least pypi and conda, our two primary delivery mechanisms) that can leverage offline mirroring.

While we're imagining a relatively small number of "kitchen sink" builds will cover many use cases, there will be the option to be to install additional extensions for an end user, which might trigger rebuild. We had been wrestling with this concept for years, but yarn might finally bring it home!