fix documentation and subtype for optimizer

[matbesancon]

There is a sentence probably left from older version implying that there are only two solvers, while any MOI-compatible LP solver will do

[devmotion]

IIRC the formulation in the docstring is intentional as these are the only two optimisers that are tested.

[matbesancon]

Given that MOI is a stable package that itself tests the contract of solvers, and that no internal feature of either solvers is used (EOT uses only standard MOI functions), I don't think the doc needs that level of caution

[devmotion]

that no internal feature of either solvers is used (EOT uses only standard MOI functions), I don't think the doc needs that level of caution

I don't know, based on #39 my impression is that the code requires features that even Clp does not support anymore. When loosening the docstring, probably users might be inclined to try even more optimisers and expect them to be supported, so it might be good to at least check more explicitly for the required features in our code and throw more descriptive error messages (e.g. suggesting one of the tested optimisers).

[matbesancon]

The problem is not solver-dependent, it's about the conventions of the solver themselves. Clp does not support incremental changes, a bunch of solvers are like that, a solution would be to use the two-argument optimize!:
https://jump.dev/MathOptInterface.jl/stable/reference/models/#MathOptInterface.optimize!-Tuple%7BMathOptInterface.ModelLike,%20MathOptInterface.ModelLike%7D

or equivalently MOI.copyto!

I'll add a fix in this PR and rename it

[devmotion]

It supported it in previous versions as it was working previously. There must have been an upstream change.

[matbesancon]

yes essentially Clp does not support adding variables IIRC, and there was before an additional layer in the Clp wrapper that was compensating this. The whole JuMP ecosystem tried to make wrappers thinner by moving these additional layers out.