fixing builder design pattern + adding dependencies null check
All transaction methods prepare(), commit() & rollback() can be called only once
additional test scenarios - ommiting transaction.prepare method call
adding empty transaction tests
introducing utility methods for test setup & tearDown
eliminating good-for-nothing PREPARE_UNDOING transaction state
refactoring abstract test class to util package
first transition test and failing
renaming transition NEW_to_CANCELLED -> NEW_to_TERMINATED
Fixing TaskControllerImpl cancellation issue:
 * removing FLAG_CANCEL_REQ check from execCancelled() - the flag is never set when Executable.cancelled() is called
enhancing transitions test case
removing illegal EXECUTE -> ROLLBACK TaskController transition
When transaction task is terminated, decrease both unfinished and unvalidated children:
 * the main purpose of this fix is transaction state machine simplicity (when deciding about transaction transitions)
 * it is possible that either unfinishedChildren or unvalidatedChildren will hold negative values, but this is not violating correctness of transaction state machine transitions

Sample scenarios with negative values:

Scenario 1: (transaction has 2 tasks, transaction at the end holds unfinishedChildren == -1, unvalidatedChildren == 0)
 1] task1 registered with transaction (unfinishedChildren == 1)
 2] task2 registered with transaction (unfinishedChildren == 2)
 3] task1 cancels at EXECUTE state => it moves to TERMINATED state and notifies transaction (unfinishedChildren == 1, unvalidatedChildren == 1)
 4] task2 enters EXECUTE_DONE state => it notifies transaction (unfinishedChildren == 0, unvalidatedChildren == 1)
 5]
 - 5a) if transaction.rollback() is called it causes correct transaction transition from ACTIVE to ROLLBACK state
 - 5b) either transaction.prepare() or transactionCommit() is called. This causes correct transaction transition from ACTIVE to PREPARING state
 6] when task2 is terminated lately, it will cause unfinishedChildren to be -1, but this has no effect on correctness of transaction transitions
   (unfinishedChildren == -1, unvalidatedChilren == 0)

Scenario 2: (transaction has 2 tasks, transaction at the end holds unfinishedChildren == -2, unvalidatedChildren == 0)
 * the scenario description is similar to Scenario 1. The only difference is neither task1 nor task2 are cancelled at EXECUTE state
   and ROLLBACK_REQ will catch them both either at EXECUTE_DONE or VALIDATE

Scenario 3: (transaction has 2 tasks, transaction at the end holds unfinishedChildren == -1, unvalidatedChildren == -1)
 1] task1 registered with transaction (unfinishedChildren == 1, unvalidatedChildren == 1)
 2] task2 registered with transaction (unfinishedChildren == 2, unvalidatedChildren == 2)
 3] task1 cancels at EXECUTE state => it moves to TERMINATED state and notifies transaction (unfinishedChildren == 1, unvalidatedChildren == 1)
 4] task2 enters EXECUTE_DONE state => it notifies transaction (unfinishedChildren == 0, unvalidatedChildren == 1)
 5] either transaction.prepare() or transactionCommit() is called. This causes correct transaction transition from ACTIVE to PREPARING state
 6] task2 enters VALIDATE_DONE state => it notifies transaction (unfinishedChilren == 0, unvalidatedChildren == 0)
 7] transaction entered PREPARED state
 7] transaction.rollback() is called
 6] when task2 is terminated lately, it will cause unfinishedChildren to be -1 and unvalidatedChildren == -1, but again this has no effect on correctness of transaction transitions)

Scenario 4: (transaction has 2 tasks, transaction at the end holds unfinishedChildren == -2, unvalidatedChildren == -2)
 * the scenario description is similar to Scenario 3. The only difference is neither task1 nor task2 are cancelled at EXECUTE state
   and ROLLBACK_REQ will catch them both at VALIDATE_DONE state.

Conclusion: The transaction transitions from ACTIVE -> ROLLBACK or ACTIVE -> PREPARING -> PREPARED are not affected by this tricky fix.