Currently, when a range uses a pre-release, such as 1.0.0-alpha.1 -
1.1.0, all pre-release versions are being rejected when the constraint
is checked because the upper part of the range does not include a pre-release.
For example, 1.0.0-alpha.2 should match that range, but it is rejected
right now.

I have updated how we evaluate constraints so that it checks whether a
constraint part uses pre-releases OR the larger constraint range that it
is part of uses a pre-release. When either part of a range uses a
pre-release, the entire range should allow pre-release versions.

Fixes Masterminds#177

Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

Previously, I was detecting if any range in a larger constraint set contained a prerelease, and allowed prereleases for any constraint in the set. This incorrectly allowed prereleases on constraints that did not participate in a range that had prereleases.

When rewriteRange is called, we lose key information about if a constraint was originally part of a range:

1.0.0-alpha.1 - 1.0.0 becomes >=1.0.0-alpha.1, <=1.0.0

I have updated rewriteRange so that it also returns any constraints that were originally part of a range that used a prerelease. Then when we are parsing constraints, allowPrerelease on that constraint is enabled if it was originally detected as participating in a range with prereleases. This ensures that only the individual ranges have allowPrerelease enabled.

Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>

Signed-off-by: Carolyn Van Slyck <me@carolynvanslyck.com>