Bitwise constraints submodule refactor for modularity

[grjte]

This PR is a proposed restructuring of the bitwise constraints updated in #180 to address the discussion in #122. This PR is based on #180, since it hasn't been merged yet.

The purpose of this is to make sure we're aligned on syntax and submodules before we write the rest of the constraints. (although note that this is a very minor change, so updating other files would still be simple)

A couple open questions:

• are we ok with passing periodic columns in to evaluators for now? This is probably not ideal in general, but it will simplify imports for v0.3
• what do we think of using a different keyword for submodules than for the primary AIR definition? I used mod instead of def here as a proposal

[Fumuran]

Looks good to me!
I like the way we pass periodic columns to evaluators.
I like the idea of different keyword for the module.

[tohrnii]

Thank you @grjte, I left a few points of discussions/questions.

[bobbinth]

Looks good! Thank you! This is not a full review - but I did leave a couple of comments inline.

[bobbinth]

Comment for the future: I wonder if we should add some "built-in" functions to help with things like this. For example, we could have is_binary() defined on the language level so that we don't have to redefine it in different modules.

[tohrnii]

@bobbinth I was thinking we could have something like a standard lib for simple functions and evaluators like these.

[grjte]

Yeah, let's discuss this for the future. It would be a nice thing to add perhaps in v0.4

[grjte]

Thank you all for the preliminary review & discussion. I believe we're aligned on syntax for submodules now as summarized in #122 , and I've updated the PR accordingly, so it's now ready for review

[tohrnii]

Thank you @grjte, looks good to me.

[Fumuran]

Looks great, thank you @grjte!