Add a basis software transactional system

[smarr]

The general idea is that all accesses to objects and arrays are mediated via
Change objects. These keep a copy of the initial state, and a working copy on
which the transactions perform their accesses. On commit, we simply compare the
initial state with the publicly visible objects, if any change (conflict) is
seen the transaction retries. If no conflict was determined, the new state is
copied into the publicly visible object.

Transactions always succeed, this implementation automatically retries.

The initial creation of a Change object accesses the public object while
holding its lock. Similarly, on writing back changes, the lock is acquired.
Transaction commits are globally sequentialized on a single lock.

Method and blocks executed inside a transaction execute an atomic variant of
their method body. All invocable used in the transactional context, i.e.,
within a atomic: [...] execution are split from the normal methods, and
marked as isAtomic. This flag allows to insert the necessary nodes to ensure
that a transaction works on working copies private to the transaction.

To avoid issues with class identity, the slots storing lazily allocated class
objects are ignored when comparing and updating objects.

Inspired by: Transactional Memory for Smalltalk
L. Renggli, and O. Nierstrasz. In Proc. of ICDL, 2007.
DOI: 10.1145/1352678.1352692

[coveralls]

Coverage increased (+0.8%) to 79.289% when pulling bbdd7de on threading/transactions into f89d1af on master.