Creating/destroying two-way bindings is unsupported during transactions

[lorentey]

Issue #6 updated bindings for the new transactional updates, but it did not add full support.
Specifically, setting up or tearing down two-way bindings during an active transaction remains unsupported, and traps if you try.

It is unclear if this will cause problems in practical apps — assuming bindings are set up during in UIViewController's viewWillAppear and destroyed in viewDidDisappear, they would normally be outside of any active transaction.

If it did cause problems, however, we have are a number of ways available to support mid-transaction bindings.

1. Delay formally establishing/destroying the binding until the current transaction finishes. This seems easy enough to do (we just need to add a little more complicated state machine in BindConnection/BindSink), but it might break people's assumptions about how bindings interact with transactions. Note that changes must start getting propagated immediately when the binding is set up, and the value must stop getting synced immediately after unbinding—only transaction boundaries may get fuzzed when necessary. Bindings may survive BindConnection's deinit in this system, so state management must be moved to a new private class.

2. Handle the underlying issue of needing to keep track of the origin updatable for each transaction. (When unbinding the two updatables, we need to split the pool of active transactions by assigning each to the updatable that originated it.) One way to do this would be to change the transaction system such that not just the outermost begin/end messages are propagated to subscribers, but also nested ones. We would probably also need some form of unique transaction ID embedded in begin/end messages — the binding needs to recognize loopbacks for messages it forwarded itself and differentiate them from messages notifying about nested transactions coming from outside.

3. We could perhaps collapse updatables that are bound together into a single logical entity. The original components would still keep track of their subscribers and number of outstanding transactions, but they would let the unified entity handle all messaging. The problem with this approach is that it would considerably complicate the Source API.