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.
Allow adding tasks for dependencies in TERMINATE_WAIT or TERMINATED state (e.g. cancelling tasks at EXECUTE state)
refactoring test framework plus adding some new tests
According to our IRC discussion ValidateContext doesn't extend CancellableContext anymore
 * ValidateContext doesn't offer cancel() anymore
 * task controller will transition from VALIDATE to ROLLBACK_WAIT if ROLLBACK_REQ is present
 * removing SEND_CANCEL_DEPENDENTS from ROLLBACK state
 * eliminating SEND_ROLLBACK_DONE event and introducing SEND_TERMINATED instead (to don't miss cancelled dependents notifications)
Eliminating EXECUTE_CANCELLED and replacing it with CANCEL_REQ persistent flag.

EXECUTE_CANCELLED flag is not presistent and so it is causing the following issue:
 * task1 is installed to transaction
 * task1 cancels at EXECUTE and moves to TERMINATE_WAIT, fires SEND_CANCEL_DEPENDENTS event
 * task2 is installed to transaction, depends on task1 (it missed SEND_CANCEL_DEPENDENTS event)
 * since EXECUTE_CANCELLED was not persistent flag, this installation of task2 is successful
   and task2 continues to execute. This is wrong, task2 have to be forced to cancel.
fixing copy/paste error
Fixing test suite reliability. It is possible that there are
not handled events in the executor when executor is shut down.