Commute upgrade.

It's hard to prevent someone from reading other, unpredictable fields while
in a Commute(). So, this commit changes things to make this possible without
weird behaviour.
* A commute may trigger other commutes, but the Shield always makes sure to
execute them in order as they were defined. It will, when it needs a certain
commute executed, execute all that were defined before it. The only safe way if
they're reading from one another. (See ComplexCommuteTest in BasicTests.)
* Commutes may now conflict with main transaction. Main t. will have advantage,
which means that even though the commute could have read newer data, the
commit check will insist that the data had not changed since main t. start, so
the commute lost it's edge by conflicting with main t.
* No more nested commutes - when a commute degenerates, his nested commutes
would just get added to the commute list - at the end of it! This meant potential
changes in commute ordering caused by partial degeneration. Not possible any
more.
The commutes are now much safer in the event of degeneration, and tolerate
pretty wild uses. You could now, for example, modify a field in your transaction
and then commutatively increase another field by the value of the first field, and
it would behave as expected: if the field you're incrementing changed, only the
commute is retried; if the first field changed, the entire transaction is retried.