CommitBarrier implementation revamp

[nbronson]

The current CommitBarrier implementation has complex interactions with CCSTM's contention management and forward progress guarantees, and requires separate cycle detectors. The fundamental issue is that it violates the atomic block -> priority assumptions used by the contention management algorithm, and blocks transactions after they have become uncancelable. I've put in several workaround for this, but this is turning into whack-a-mole and injecting complexity deep into the core. As of 1f97ae8, there can still be deadlock cycles that traverse multiple transactions and multiple commit barriers. We need to revamp this design to have simpler correctness reasoning. The current implementation isn't robust, so it is likely that nobody depends on it.

Possible strategies:

• run all members at the same priority, and roll all of them back if any of them roll back
• block members in the Preparing state until all of them are ready, so that they don't wait in an uncancelable state