Option to include prereleases when matching npm/cargo ranges

[andrew]

Range.Contains gates npm/cargo prereleases through semverIntervalAllowsPrerelease (range.go:64), which only admits a prerelease when a bound in the same interval carries a prerelease tag on the same major.minor.patch. That matches node-semver's default and is right for dependency resolution, but advisory matching needs prereleases inside the numeric range to match regardless of the bounds:

r, _ := vers.ParseNative("< 3.0.0", "npm")
r.Contains("1.7.0-alpha.2") // false; advisory matching wants true

node-semver exposes this as includePrerelease: true. One shape here would be a variadic option on Contains and Satisfies:

r.Contains("1.7.0-alpha.2", vers.IncludePrerelease())
vers.Satisfies("1.7.0-alpha.2", "< 3.0.0", "npm", vers.IncludePrerelease())

or a parallel method if changing the existing signatures is unwanted.

Same gap as andrew/vers#38 (Ruby side, fixed in andrew/vers#41).

[itsumida]

A concrete case from advisory matching, in v0.7.1:

r, _ := vers.Parse("vers:npm/>=16.0.0|<16.3.3")
r.Contains("16.3.0-canary.97") // false

OSV advisories for next use ranges like this one, so canary builds inside them are not flagged. For vers: URIs the spec only orders versions, so it would help if they included prereleases by default, with the node-semver rule kept for ParseNative. The opt-in you suggest would work for us too.