fix #112

[ulfworsoe]

Fixes issue #112 but introduces another failing test. I think it is unrelated to 112.

[blegat]

I looked into the failure and I think it is related to the deletion of ACC. The tests sets a quadratic objective, then sets a different one and check that it gets the different one with MOI.get. This quadratic bridge is transformed into a rotated second order cone constraint by MOI. The first objective adds a SOC constraint for rows 1 to 5. Then, when setting the new objective, the MOI bridges first delete the constraint and then add a new one. Since getnumafe is still 5 after the deletion, it uses the rows 6 to 10. So we get 6:10 here: https://github.com/jump-dev/MosekTools.jl/blob/b47cd76235725e30171f20027c2658c778f7087a/src/constraint.jl#L639 If I change this line to a hardcoded line: r = 1:5, the test pass. This is weird since the rows used in rsubi here: https://github.com/jump-dev/MosekTools.jl/blob/b47cd76235725e30171f20027c2658c778f7087a/src/constraint.jl#L536 are

rsubi = [7, 8, 8, 9, 9, 10]
rsubj = Int32[4, 2, 3, 1, 2, 2]
rcof = [-1.0, 1.0, 2.0, 2.0, 1.0, 1.4142135623730951]

So putafefentrylist is called with the rows between 6 and 10 after the deletion, and then when getting the rows in getaccftrip, we get the rows shifted by five even if there were no deleting in between the two calls as the deletion precedes both call.