Multi dimensional element constraint

[Dimosts]

Adding Multi-Dimensional Element constraint separately than 1D Element. The main reason is to allow us to safen the indices, as the way we have it now we lose information for the different indices.

[IgnaceBleukx]

Great! I have some (mostly minor) comments on the code, but the CI seems to be failing for PySAT, not sure why...

Other thing is the name, personally I like MultiDElement, what do you think?

[Dimosts]

Fixed the issue with pysat, it was a memory thing, just reduced the size of the array in the test and done. Also resolved the comments, improving based on the suggestions, and adding additional tests.

About the name, I do not have any strong preference, will change it to MultiDElement.

[IgnaceBleukx]

Great! Not sure if the helper function is really required?
Also, MultiD element is also supported in MiniZinc, right? So we should also add it to our interface.

I quickly checked for other solvers, they don't seem to support it.

[tias]

NDElement, like we have NDVarArray?

(no real objection to MultiDElement though)

[Dimosts]

No real objection or preference to the name on my side either.

On another note though, I did some experiments on using minizinc's multi dimensional element, or decomposing it ourselves.

And it seems that our decomposition is quite better. So, although minizinc does support it, I think we should not put it in its supporting list.

My experiments used the Quadratic Assignment Problem, using a 2D element constraint in defining the objective. The main parameter is n, the number of locations, which also defines that the array (to be accessed) is nxn. I experimented with n = 6...10.

Note that in the figure, the time is in log scale.

[IgnaceBleukx]

Interesting, is this with gecode or OR-Tools as backend? I would still prefer to not decompose it, as users may want to use a solver with minizinc that does support native 2d element constraints.

[IgnaceBleukx]

Renamed to NDElement, and merged current master into this one.
Should be ready for final review by @tias

[tias]

I added some stricter typecheck to the constructor; well, an assert actually, and had to update a test.

our safen has a 'safen_toplevel' that multiple solvers have to fill in with 'element', 'div', mod'... should we also add nd_element there?
More generally, safening docs don't mention nd_element yet

we now have a decompose_linear for element, do we also need one for nd_element?

I also followed an agent recommendation to extend a test...

also small bugfix in choco's added objective safening

other than that its looking good so far...