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
If anybody tried to add a header, they would get duplicate symbol linker
errors.

On Friday, August 1, 2014, Anthony Scopatz <notifications@github.com> wrote:

> In src/solver_factory.cc:
>
> >  #include "error.h"
> >
> >  namespace cyclus {
> >
> > -// - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > -SolverFactory::SolverFactory(std::string t) : t_(t) { }
> > +/// An event handler that records the time that a better solution is found
> > +class ObjValueHandler: public CbcEventHandler {
>
> 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.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/cyclus/cyclus/pull/978/files#r15714324>.
>