Transaction manager run problems

[jimfulton]

1. When the number of retries has been exceeded, we don't abort the transaction. We should always abort and then raise.

2. The run implementation doesn't account for application code creating new transactions. This is an important use case. Consider an application that catches errors, and needs to record information about the errors transactionally. In this case, the application aborts the current transaction, uses a new transaction to record some information, or otherwise recover. The run implementation should use the transaction manager methods to do it's work, rather than assuming it can interact with the initial transaction. Currently, an error is raised if the transaction changes.

[d-maurer]

run is not mentioned in transaction.interfaces.ITransactionManager.