Throw PessimisticLockingFailureException/CannotAcquireLockException instead of plain ConcurrencyFailureException

[jhoeller]

Related to #29511 and the general default change to SQLExceptionSubclassTranslator in 6.0, it would be helpful for typical application-level handling to identify pessimistic locking cases without relying on specific subclasses such as ConcurrencyFailureException and DeadlockLoserDataAccessException.

As a consequence, SQLExceptionSubclassTranslator and SQLStateSQLExceptionTranslator should throw PessimisticLockingFailureException instead of the superclass ConcurrencyFailureException for database-level concurrency failures, more strongly differentiating such database lock consequences from OptimisticLockingFailureException at the ORM level.

Also, SQL state 40001 is commonly reported for lock acquisition failures, so we should turn that specific case into CannotAcquireLockException specifically.

The combination of the above is expected to reduce the need for DeadlockLoserDataAccessException and CannotSerializeTransactionException which are not supported by SQLException and SQL state classification. Those exception subclasses are marked as deprecated now but still thrown from corresponding SQL error code mappings (but not by default anymore).