Update docs and cleanup

[ericphanson]

Summary

• The first commit essentially updates the docs in light of the need for Cache conic forms between solve!s? #318.
• The second commit just fixes some broken references in the docs
• The third commit finishes something promised in Remove global variables #322, namely removing unused and incorrect optional arguments.

Docs changes

The page Optimizing in a loop caught my eye because thanks to #322, we no longer need Convex.clearmemory(). Unfortunately, however, the rest of the page isn't really accurate either: it promises performance gains thanks to caching conic forms between solves.

In fact, I'm not really sure when it was true. The only global caches we had as of #322 were id_to_variables and conic_constr_to_constr, neither of which cached all conic forms. Rather, these were registries to look up a particular object (a variable by it's id, or a constraint from its ConicConstr). Neither provided a mechanism to store conic forms between solve!'s of a particular problem or between different problems.

The wording of the first sentence of the removed page "Convex uses a module-level dictionary to store the conic forms of every variable and expression created in the same Julia session" quite unambiguously disagrees with my assessment above. I'm not sure if it was true in the past, but at least it no longer held by the time I got to doing #322, since I removed the last globals and neither provided a way to not recalculate conic forms.

Since we don't have #318 solved yet, fix!ing and free!ing isn't nearly as helpful as it should be either for optimizing in a loop. Hence, the page doesn't really have any good info currently.

Hopefully we can fix #318 and then put this page or a similar one back.

Optional arguments

The third commit looks scary at first: it removes the optional argument UniqueConicForms() to every conic_form!. In fact, that optional argument is never used (as shown by eg CI passing on this PR). Moreover, if that optional argument was used, it would silently cause Convex formulate incomplete problems. That's because we pass around a UniqueConicForms object and populate it with all the problem data. If we created a new one at some node in the problem tree and started populating that, we would lose the problem data from that node down. Since at the end, we assume the UniqueConicForms object we passed in at the start (currently in Convex.conic_problem, in #330 it will be in load_MOI_model!) was populated with all the data.