add build_spec module, not yet used in match_spec

[YeungOnion]

this creates the module to define and parse the build number spec

Next PR will use the parsing and matching in crate::match_spec

[YeungOnion]

Whoops, forgot to make a PR for the other two changes. I'll separate those out and then mark this as ready.

• add pixi task for cargo to expose cargo
• seemed like version_spec::constraint::Constraint shouldn't be explicitly used outside of the version_spec module since we just parse as a whole VersionSpec and call VersionSpec::matches

[baszalmstra]

Nice work @YeungOnion ! I merged the first two PRs

[YeungOnion]

One of these CI failures is from not calling build_spec::BuildNumberSpec::matches. I imagine that's an issue as it's not part of an API defined elsewhere so not being used means it's useless.

The only way to call it as is, would be to make all the changes in the match_spec module and that touches a few different submodules.

An alternative to pass the check is to define API at crate level and use that API in this module. All types with Spec at end of their name have matches methods. Perhaps a trait that all ...Spec would impl would be a good fit for API,

trait Matchable {
    type Record; // very open to better names
    fn matches(x: &Record) -> bool;
}

All the ...Spec types also parse from strings, but that's uncoupled.

I like the second approach, but I don't see real value beyond uncoupling the PR for build number specs into one for module and the other for usage since there aren't other types yet to create that would impl Matchable, are there? I'd just expect the ...Specs to use them. What are your thoughts on this?

[tdejager]

I think either removing it if it's unused. Or what I'm thinking you are saying is to actually change methods to use this function is a good idea.

The other alternative might be a good idea, but I agree it is out of context of this PR :)

But Ill let @baszalmstra chime in here.

[baszalmstra]

IMO we add a #[allow(unused)] with a comment that explains why it is there and merge it. I assume the next PR will start using this method? We can then immediately remove it.

I do like the Matchable idea but maybe for another PR?

[YeungOnion]

Think that'll work well. I opened the other PR about a trait providing a matches method as #345