Undo generated properties on general persistenceExceptions

[rPraml]

With #2372 we introduced a rollback mechanism when an optimisticLock happend.
This PR also handles the situation for other persistence exceptions like DuplicateKey in a similar way, so that you can correct the issue and retry save.

Please take a look, if this makes sense to you.

[rPraml]

checkme: Rename to "onExecuteUndo(ex)"?

Are there possible uses cases in CallableSql/OrmUpdate/SqlUpdate?

[rPraml]

Hmm, this is not as easy as I thought...

I would first like to ask whether the following is a valid expectation:

insert/update

• If I have an entity and I try to insert/update it and I get an exception (e.g. DuplicateKeyException), it should be possible to save the entity again, after correcting the error.
• between the first and second save, several minutes can pass. So the @WhenCreated + @WhenUpdated should be the time, when the entity was effectively saved.

delete

• If I get an error when deleting an entity (e.g. ref-integrity-error) - it should be possible to delete the entity again, when the problem is solved.

The above is easily accessible for noBatch. I extended #2372 that insert/update/delete undoes exactly the properties, that were modified. (dirtyGenerated properties)
It is done on each exception now and not only on OptimisticLockException. This is done in DmlHandler.executeNoBatch()

The batch case is more complex:

We might have several BatchedPstmts, maybe for different beans. If one of them will fail in the transaction, we have to undo all of them. So we might save 1000s of beans in one transaction and the txn.commit() will fail, so we must undo all of them - or - at least to the last commitAndContinue/savePoint.

I'm a bit unhappy about the solution, because it will not work reliable. There are list.clear()s - that may make a proper undo impossible. OTOH to implement a proper solution, this means, that we have to keep all beans in memory, until the transaction is committed.

@rbygrave How do you see this? Is my assumption already wrong? Or can we only guarantee this in noBatch mode?