Support for reversion in Transformation

[qtothec]

This is a design discussion to talk about support for reverting transformations, raised by @whart222 in #196.

The use case is:

MINLP --> fix binaries --> NLP --> remove trivial constraints --> solve NLP --> generate cut --> unfix binaries --> MINLP

I also want feedback on the proper implementation for supporting reverting transformations. I see multiple possible approaches:

1. I store the necessary information for reversion as a ComponentSet or ComponentMap on the model instance itself.
2. I store the necessary information for reversion on the Transformation object.

Possible edge cases/complications:

1. Transform model A, clone model A, revert on model A clone
2. Transform model A, different transform on model A, original transform on model A again, revert second instance of original transform, revert first instance of original transform
3. Transform model A, different transform on model A, original transform on model A again, revert all instances of original transform

[carldlaird]

Thanks, Qi. This helps seed the discussion.

[emma58]

This discussion has come to a head again because we have good reasons for wanting to reverse the gdp.fix_disjuncts transformation. I would like to:

1. Strongly vote that we store the necessary info on the model, not the Transformation object. We (I) have been burned by storing state on transformation objects far too often, and in addition I think it is very confusing from a user perspective if a transformation cannot be reverted by a different instance of the transformation, especially since many of our examples are written as TransformationFactory('foo').apply_to(...), so TransformationFactory('foo').apply_to(..., undo=True) seems quite natural. In addition, this will make @qtothec's cloning edge case above work.
2. @qtothec raises some good points above about edge cases where someone would expect reverting multiple transformations to work. It seems reasonable to me to require that they are going to revert in the opposite order that they transformed (just noticed "vert" is a lost positive...). However, if we want to at least raise a helpful error message when someone violates this, we are going to need all the revertible transformations to use the same convention for storing the state they might need later, and to do this in such a way that they know in what order they were applied. Would it be possible to claim a name (perhaps on all Blocks?) where we could stick a dictionary or something with this information?

@jsiirola, @blnicho, others: Thoughts?