A little Shield.SideEffect safety.

The method lacked a check for transaction status and would throw a NullRef
exception if called out of transaction. It will now, if called out of transaction,
directly execute the onCommit action. This allows the possibilty of designing
a method which may consist of multiple transactions when executed alone, but
safely merges into any larger transaction when it gets called from it.

I believe the best way to design methods, though, is to either open your own
transaction covering the whole method, or to assert at beginning that you
already are in one. When they need a specific transaction status, methods in
Shielded will open their own if their action is equivalent to a read-only op, or
assert that they are already in one if they will produce any change.
A new test, reveals an issue.

Combination of commute and pre-commit check is potentially
dangerous due to the pre-commit checks not being isolated like
the commutes are. Due to this, the pre-commit check triggered
within a commute sub-transaction can read something read in the
main transaction, and potentially see a different, newer value.
Such a transaction would be retried, but the pre-commit might
throw an exception before that, thinking that a transaction is
trying to break an invariant.
Fix for the CommuteInvariantProblem.

While a pre-commit is defined for a field, you cannot commute over it. The
pre-commits cannot execute in the commute sub-transaction, as they might
access out of it's limited field set and see inconsistent state. So they execute
before, causing commutes to degenerate.