Allow pre-releases when the range uses them

[carolynvs]

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 #177

[mattfarina]

Note, I have ideas how to modify this work so it only checks prereleases on the prerelease ranges. It involves some deeper cutting changes. If you want, I can pick up the work from here and try to change it.

[carolynvs]

Ope, sorry for the slow turnaround, I was on vacation for a couple weeks there. I'm back now and have a bit of a start on handling the case you added.

[carolynvs]

After looking at it more, I'm not sure how best to go about only applying the pre-release to a single range, since the range is immediately removed and converted into another representation when the constraint is parsed. If you have an idea for how to make this work well, please have at it! 👍

[draithat]

Any updates on this request?

[carolynvs]

@mattfarina Sorry for the really long delay getting a fix for the test case you brought up. Please take another look?

[carolynvs]

I've fixed the merge conflict and this is ready to review.