Class: Transaction

`Transaction` creates a black box that is able to wrap any method such that certain invariants are maintained before and after the method is invoked (Even if an exception is thrown while invoking the wrapped method). Whoever instantiates a transaction can provide enforcers of the invariants at creation time. The `Transaction` class itself will supply one additional automatic invariant for you - the invariant that any transaction instance should not be run while it is already being run. You would typically create a single instance of a `Transaction` for reuse multiple times, that potentially is used to wrap several different methods. Wrappers are extremely simple - they only require implementing two methods.

                      wrappers (injected at creation time)
                                     +        +
                                     |        |
                   +-----------------|--------|--------------+
                   |                 v        |              |
                   |      +---------------+   |              |
                   |   +--|    wrapper1   |---|----+         |
                   |   |  +---------------+   v    |         |
                   |   |          +-------------+  |         |
                   |   |     +----|   wrapper2  |--------+   |
                   |   |     |    +-------------+  |     |   |
                   |   |     |                     |     |   |
                   |   v     v                     v     v   | wrapper
                   | +---+ +---+   +---------+   +---+ +---+ | invariants
perform(anyMethod) | |   | |   |   |         |   |   | |   | | maintained
+----------------->|-|---|-|---|-->|anyMethod|---|---|-|---|-|-------->
                   | |   | |   |   |         |   |   | |   | |
                   | |   | |   |   |         |   |   | |   | |
                   | |   | |   |   |         |   |   | |   | |
                   | +---+ +---+   +---------+   +---+ +---+ |
                   |  initialize                    close    |
                   +-----------------------------------------+

Use cases: - Preserving the input selection ranges before/after reconciliation. Restoring selection even in the event of an unexpected error. - Deactivating events while rearranging the DOM, preventing blurs/focuses, while guaranteeing that afterwards, the event system is reactivated. - Flushing a queue of collected DOM mutations to the main UI thread after a reconciliation takes place in a worker thread. - Invoking any collected `componentDidUpdate` callbacks after rendering new content. - (Future use case): Wrapping particular flushes of the `ReactWorker` queue to preserve the `scrollTop` (an automatic scroll aware DOM). - (Future use case): Layout calculations before and after DOM updates. Transactional plugin API: - A module that has an `initialize` method that returns any precomputation. - and a `close` method that accepts the precomputation. `close` is invoked when the wrapped process is completed, or has failed.