quadratic objective support

[mlubin]

• Complete operator overloads, e.g. AffExpr*Variable
• Get rid of objIsQuad structure -- it really messes with type inference. Instead there should be separate quadratic and linear parts of the objective as members of Model. If there is a quadratic part, then m.affobj can point to the same object as m.quadobj.aff, for example.
• Clean up and document using Gurobi for quadratic objectives, as added in 3db9f64. Alternatively (in the long term) push this into MathProgBase.
• Macro support.

[IainNZ]

On the 2nd point, do you mean we should just having a m.quadObj and m.affObj, and m.quadObj can be nothing?

[mlubin]

m.quadObj should always be a QuadExpr (but it can have zero terms), and m.affObj should always be an AffExpr.

[IainNZ]

Operator overloads are done, I think. Needs testing to ensure that though.
See notes in QuadExpr test with regards to the issue of Q being symmetric or lower triangular. I guess this can really just be done at the end, but maybe we should cram it into pretty printers. Very low priority.

[IainNZ]

I also renamed some of the fields of QuadExpr to make it less verbose and camel-casey

[IainNZ]

About to tackle point 2

[IainNZ]

Ok, done, I think. Tests pass, but we don't have a quadratic objective test yet!
ba0ba53
Basically, removed objective and quadObj and isObjQuad and just have a single objective field that is a QuadExpr (and thus has an AffExpr in it). From then on was just a matter of replacing isQuadObjs with length checks on quadratic part of objective.

[IainNZ]

Do you want to do point 3? I see you've started on it. If not, I'll do it.

[mlubin]

Done. All that's left is macro support, but I'm not sure if I'll get to that in the short term.

[IainNZ]

Future work then - I don't think its a priority