Redesign TxManager interface

[lavrukov]

Right now, TxManager seems to mix two responsibilities: the actual logic for executing and retrying transactions, and the configuration. If you think about it that way, it turns out that TxManager is ALREADY a decent builder; we just need to extract the core into a separate class to make it easier to build upon the logic. In our projects, users use DelegatingTxManager or their own implementations of TxManager exclusively for adding wrappers around the tx() method.

Here's how I see it:

• Extract the part with the tx() method from TxManager into a separate interface, let's call it TxManagerLogic for now. StdTxManager will start implementing this and only this. This is the core that users want to wrap. People aren't interested in changes to the With methods (or maybe we can handle this differently).
• Now, TxManager essentially becomes a TxManagerBuilder. Most likely, it becomes so simple that the interface can be turned into a final implementation. Essentially, it now build an options object and, at the moment of tx(), simply calls this.txLogicCreator.createTxLogic(options).

In this story, we need to reconsider readOnly() and scan().