Removing Arjuna integration
Implemented Rs/W transactions idea. See attached IRC log bellow for more details:

<dmlloyd> I wonder if maybe we should have read-only transactions too, for query operations
<dmlloyd> because those we can have many of at once
<dmlloyd> and we could use upgrade/downgrade operations as well

<dmlloyd> was thinking a little bit about a txn api to go with our discussion yesterday
<dmlloyd> if we had: interface ReadTransaction { ... }, interface UpdateTransaction extends ReadTransaction { ... }
<dmlloyd> we could confine each operation based upon whether it is update or read/update
<dmlloyd> then the transaction controller API would have methods like: void startReadTransaction(Listener<ReadTransaction> listener);
<dmlloyd> void startUpdateTransaction(Listener<UpdateTransaction> listener);
<dmlloyd> void downgradeTransaction(UpdateTransaction transaction, Listener<ReadTransaction> listener);
<dmlloyd> boolean upgradeTransaction(ReadTransaction transaction, Listener<UpdateTransaction> listener);
<dmlloyd> internally there could be some kind of queue
<dmlloyd> each item in the queue can be a single waiting updater, or a set of waiting readers
<dmlloyd> opening a read transaction -> if the queue is empty and the current txn is read, join readers, else look in queue:
          if tail of queue is a set of readers, join it, else add a new reader set to the end of the queue
<dmlloyd> opening a new update transaction -> if no transaction is active, open, else add a new updater to the end of the queue
<dmlloyd> downgrading -> invalidate current UpdateTransaction object, convert current update txn to read txn;
          if head of queue is a set of readers, dequeue allow all readers in the set to join the transaction; return new ReadTransaction
<dmlloyd> upgrading -> if queue is empty, add updater to queue with same txn object as the current reader & return true, else return false (cannot upgrade)
<dmlloyd> in the upgrading case the user could still use the same ReadTransaction object (it is harmless to do so)
<dmlloyd> in the downgrade case we probably don't want to do that since only the Update half of the interface will be invalidated
<dmlloyd> the downgrade method could return the ReadTransaction directly though instead of going through a listener, since there is never a wait to downgrade
<dmlloyd> also, downgrading should only be possible if no update actions have occurred
[MSC2-6] Downgrading an update transaction should retain its position in queue
[MSC2-7] Upgrading an already-upgraded transaction should return true
[MSC2-8] enhancing TransactionController transaction lifecycle methods signature
Eliminating useless PrepareResult.isPrepared() method
Eliminating useless getRollbackReport() method
Eliminated abort and rollback phase usages from test suite.
Eliminating CancellableContext
Hiding Revertible interface from public API
Eliminating rollback() and abort() transaction methods
Eliminated ROLLBACK & ROLLED_BACK transaction states
Eliminated ROLLBACK_REQ & SEND_ROLLBACK_REQ from task controller implementation
minor code cleanup - fixing warnings and eliminating unused methods
Hiding Executable, ExecuteContext, TaskController and TaskBuilder from public API.
Implemented support for transaction restart() as alternative to eliminated rollback() and abort()
Removing useless assertion statement.

Currently even problematic transaction can be committed
and such assertion might be violated sometimes.
Add ide config files
Remove unused method from StartServiceTask.
Fix stack overflow issue involving service starting notifications