Cache conic forms between `solve!`s?

[ericphanson]

Right now, calling solve! calls conic_problem which makes a new UniqueConicForms() object, then fills it up by recursing down the tree which constitutes the problem via conic_form!. Then if you say fix! a variable to a different parameter, or change the objective, and solve! again, it again calls UniqueConicForms() to make a unique conic forms object, fills it up, etc.

So if I'm understanding the code correctly, in the end, nothing was saved as compared to making a fresh problem with the new value of the variable; the only caching is between conic forms reused within the same problem present simultaneously when solve! is called.

I think one solution to this is to keep a problem-local unique conic forms object, which holds onto every conic form seen by that problem (not a global one to prevent memory issues like in #83). That way, reusing a problem can reuse the conic forms it's already calculated.

One problem I forsee is fix!ing a variable (or free!ing a fixed one, or changing the value of a fixed variable); we need to recalculate conic forms involving the variable in that case. I think a solution to that when we hash a variable, we include its fix! vs free! status (i.e. the vexity) of the variable, and either its value, or maybe just a counter indicating how many times the value has been changed.

Also, I notice sometimes hash is used just with the children of an atom, and sometimes the head of the atom is included too. I should figure out why that is, and if it could lead to bugs.

The other difficulty is that currently, the whole constr_list of the unique conic forms object is used in conic_problem; if we keep a problem-local running cache, we have to figure out which cached conic forms we actually want to use for the problem.

Another possibly good change is to have UniqueConicForms to hold its own id_to_variables, keeping track of the variables used in the conic forms it caches. That could replace the global id_to_variables dictionary by a local one. The only catch there is that variables constructed internally in the conic_form of expressions need to be included, not just variables directly used in atoms. This can be separate from the problem-local UniqueConicForms though.