add support for disjunction constraints

[ctdunc]

Adds preliminary support for disjunctive constraints, and new methods for creating constraints without adding them to the problem itself.

Long-term, it may be nice to have a slate of methods like createCons<T>() which create constraints without adding them to the problem, and .addCons<T>(<T>) methods which can take constraints as inputs, so that we can add more support for compound constraint creation methods like conjunction,

[Opt-Mucca]

@ctdunc Good changes! I think they add more functionality, and I am all for supporting more constraint classes.

My current concern: The naming of createExprCons. An ExprCons is already technically created by the user when calling such a function. The function is rather creating a PySCIPOpt Constraint object. I feel like the name createCons will lead to a lot of confusion though. I am concerned about users using such a function and then trying to call addCons with the resulting object. I will need to discuss with @mmghannam and @Joao-Dionisio

Aside from that: The code looks good and just has some minor things to tidy up.

[ctdunc]

Thanks @Opt-Mucca ! I chose ExprCons since every other addCons<T> method also creates a python Constraint object. This one creates a constraint from an expression. I am not particularly attached to this naming convention. Maybe something like createConsFromExpr would work?

Fwiw i also think it would make sense to have addCons accept a python object as an input rather than an expression (especially as more support for composed constraints is introduced) to be more consistent with the naming convention of other methods. However this would be a significant breaking change.

[Opt-Mucca]

@ctdunc Thanks for this merge request! This is a really cool feature.

I've changed some minor things that I raised earlier. I renamed the function createExprCons, and moved some of what I believe were leftover debug stuff.

I'll now merge the branch! For your comment on adding a cons with a Python object: I agree. Given that users can now create a constraint object easily, they should be able to pass it as an option to addCons. This goes on the TODO list.

[ctdunc]

Looks great! Thanks for including :) Have been a bit tied up with other project at work, but hoping to get back to this soon.
Having had a bit more time to dig around in getting user-provided decompositions working, I agree with these name changes. Since the underlying SCIP structures typically require a pointer to a SCIP problem, it doesn't really make sense to allow users to create python objects independently of a SCIP Model().

If my understanding of this is wrong, please LMK as I have more features I would like to attempt to contribute & want to avoid this type of confusion going forward. Thanks :)

[Opt-Mucca]

You're understanding is correct! A SCIP pointer is in general always required, and therefore does handicap creating Python objects independently. Very happy for any other contributions when you have the time (I will get to the user defined decompositions in the next week or two)