Cyclopts

This is a PR of the current changes to Cyclus required for my present work (I wanted to get one in before it got too large). This PR is largely comprised of:

* updating the OSI header files from an errant sed 's/model/agent/g'
* fixed a bug in exchange graph translation that did not account for the exclusivity flag
* all solvers now return objective values
* the calculation of costs associated with unmet demand are now shared by all solvers through the ExchangeSolver API
* the prog solver now uses a cbc CLI-like solve (it's much faster)
* the greedy solver now copies any state of exchange graph that it mutates
Well, to be a little clearer on the terminology, this class as written isn't unreachable - it is just unadvertised.  Anyone could write the header for this class and use it when linked against libcyclus.  If unreachability is desired, then it should be truly unreachable.  As a feature, this leaves a lot to be desired.

I agree that nested classes are weird, but they solve the problem.  What would be a better and more normal solution that accomplishes unreachability would be encapsulation of the class in an anonymous namespace.

That said - I don't see much value in having completely unreachable classes and do see it as a potential future maintenance headache.  The moment someone, anyone (including us) wants to use the class at all for any reason (including testing) then we have to write the declaration in an header anyway. The person best equipped to write that header is the person who originally wrote the definition in the moment that they are writing it.  It is more work for themselves and other to not do it in the moment.

Additionally while I agree that the ideal of a concise API is great, it *has* to be balanced against the competing ideals of having a well-tested code base and having small code units.

In summary, I don't think that unreachable code is a great idea for classes and even if it was desired it wouldn't be implemented as is.