Handle core module versions in snapshot

[miyagawa]

This is a major change in how core modules pinned in the snapshot works.

Context

34b3687 combined with 8ea6b68 introduced a bug where a core module pinned in the snapshot has always been ignored in the first carmel run (i.e. when the pinned version doesn't exist in the artifact repository).

If a version is pinned in the snapshot and has a higher version than the version shipped with perl, it's clear that Carmel should install that version. This is now fixed in this PR.

Core Module in the Snapshot

If a version is pinned in the snapshot and has a lower version than core, it gets a little messy. Technically you could do this, but is difficult to implement with Menlo, because Menlo automatically skips this dependency, unless you pin to the exact version with what's in the snapshot, which caused some issues like #33 (removed the == $ver in 8ea6b68)

In this PR, I added a workaround and a behavior change as a result, so that if:

• a version is pinned in the snapshot
• the version is not found in the artifact repository
• the version is lower than core version of the module

Carmel will ignore it and remove it from the snapshot, meaning that it would upgrade to the core version of the module. I think this is a safe behavior for core modules.

Example

# cpanfile
requires 'HTTP::Tiny';
# cpanfile.snapshot
  HTTP-Tiny-0.056
    pathname: D/DA/DAGOLDEN/HTTP-Tiny-0.056.tar.gz

Because perl has a higher version of HTTP::Tiny than what's in the snapshot, and your cpanfile doesn't specify any version, the version pinning will be removed from the snapshot, on the first run of carmel install.

If you really want to pin to the version that's older than core, you can still do this with:

# cpanfile
requires 'HTTP::Tiny', '== 0.056';

First Installation

Related to this bug fix above, there's still a chance where you encounter Can't find artifact for Module => version in the first carmel run. Here's how this happens:

• carmel resolves the dependencies specified in cpanfile and uses the snapshot to install all of them
• Some transient dependencies that are core, and pinned in the snapshot, could be missed during the first run due to how the resolver works.

Usually this can be fixed by running carmel install again. This PR updates the install code so that the retry is unnecessary - it will automatically retry until there's no new missing modules from the installation.