Add version field and constraints

[RichiH]

No description provided.

[sdboyer]

Version attached to the PollyPackage schema? Yeah, that's certainly needed.

Not sure exactly what "constraints" would be, though - say more?

[RichiH]

e.g. "match semver"

[sdboyer]

Match semver - so like a constraint range, e.g. ^v1.0.0, right? And match the semver of what - other pops on which the declaring pop depends? If so, three things:

• I'm trying to avoid thinking about cross-pop dependencies for as long as possible (though i suspect that won't be very long). It's a larger version of the question in How should signals be injected into config objects? #6 - are references to certain objects done via strings, or CUE references? - made much more complicated by being spread across repos/requiring thinking about package management.
• When we do get there, i'm gonna be pretty staunchly against using semver ranges. There's reasons, but it's too much to go down that rabbit hole right now.
• I'll be easier to move on this one, but i'm also likely to be opposed to using semver at all to version polly packages. Semver numberings only really have meaning when there's at least an aspirational rule that can be applied to decide if a given change is backwards compatible or not. I'm not sure it's possible to construct such a rule for polly.