No longer reuse directory names in the package set updater

[thomashoneyman]

The current package set updater is failing to add some packages (such as jelly@0.7.0), because it is relying on stale modules when installing a new version and compiling the package set. It is also incorrectly marking some packages as successful (such as codec-argonaut@10.0.0) for the same reason.

The root of the issue is that we are reusing the same directory name for all versions of a package. For example, codec-argonaut@9.2.0 is installed in the directory codec-argonaut. Then we compile everything, and go to install codec-argonaut@10.0.0. To do this, we delete the codec-argonaut directory, then reinstall the new version into a new directory of the same name. This is causing some confusion with the compiler, which in this case won't recompile the package at all and just reports a successful result.

While jelly and codec-argonaut are failing for different reasons and with different results, both are fixed by always installing packages into a directory containing their version (ie. codec-argonaut@10.0.0 instead of codec-argonaut). I've tested this out by running the package set updater locally for both of the affected packages, and I now see the expected success for jelly and expected failure for codec-argonaut.

You can test this locally yourself by running:

registry-package-set-updater generate

...adjusting the PackageSetUpdater module lookback from 24 hours to as far as you need to get some packages to upload, or manually changing the candidates.accepted field to include the packages you want to test

[thomashoneyman]

Note that this never affected batch uploads, and it doesn't seem to affect packages that are depended on by other packages in the set. So this most likely hasn't been an issue in previous package set releases.

[thomashoneyman]

Merging as this is affecting the current package set updater, but if needed I can circle back and address review comments.