Basic implementation & tests of implied carets

[sdboyer]

I elected to go the route of adding a method to the Constraint interface that allows the caller to decide how the constraint should be converted into a string. A bit of a kluge, but I think really the best of a bad set of options.

Fixes #41.

[sdboyer]

ping @mattfarina

[mattfarina]

@sdboyer Quick question, can't this be stored as an internal value and then merged with the other parts in the String() method? Or, am I missing something? I imagine I'm missing something so I'm asking.

[sdboyer]

@mattfarina i started with that approach initially, and yep yep, it works just fine for ranges.

the problem was actually with Version.String(). A Version doesn't know whether it's responding to Version.String() or Constraint.String(), because there's no distinction (Go doesn't make available call-site type information to a called method). This meant that, for an application wanting to consistently use implicit caret behavior, it's not sufficient to rely on Constraint.String() getting it right - ranges will, but versions will not.

Client code wanting to achieve that outcome would have to write extra logic to sniff the underlying type and do the work itself. But that gets tricky (e.g., multiple range handling within unions), so better to just make that function a part of the lib itself.

[sdboyer]

bump

[sdboyer]

sweet!