Change cp.sum(*iterable, **kwargs) to cp.sum(iterable, **kwargs)

[hbierlee]

Fixes #654. It is over-explained in the linked issue, but the discrepancy is simply this:

>>> cp.sum(1,2)
3
>>> sum(1,2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable

Allowing cp.sum(1,2) was I think accidentally introduced by #111. I believe we should follow Python's design for all builtins, but this is a breaking change, so perhaps needs to be moved to cpmpy 0.10 / stable.

[hbierlee]

I checked the behaviour again for all operators, they seem consistent with Python 3.12. No examples needed updating. So I think this is good to merge.

One more change I propose:

The straightforward way to check that our cpmpy override behaviour is the same as the python built-in is by comparing the signatures. Currently, they are the same, except for max and min, which for Python is:

max(arg1: SupportsLessThanT, arg2: SupportsLessThanT, /, *_args: SupportsLessThanT, key: None=...) -> SupportsLessThanT

but we have:

max(*iterable, **kwargs)

The behaviour is almost the same, except that we'll get a slightly different error. I will align that as well, then it's ready for review/merge.

[hbierlee]

Ok, I looked into getting the same type signature for max/min, but it seems overkill for our case. It uses some pretty extensive typing to accomplish the argument overloading with @overload (https://typing.python.org/en/latest/spec/overload.html), plus there are not 2 but 6 max overloaded functions. I think our current solutions suffices, you almost get the same error as in Python, just from within the function rather than from the top.

To maintain this kind of complexity, we'd need some way to dynamically get the same signatures as the Python built-ins, but this is also out-of-scope.