Support transaction isolation levels when using the JDBC transaction support

This should allow transaction isolation levels to be supported
on the following jdbc subadapters: as400, db2, derby, firebird,
hsqldb, oracle, progress, cubrid.
Support transaction isolation levels on Oracle and DB2

Both Oracle and DB2 appear to support the SQL standard way of
setting transaction isolation levels, but the non-JDBC adapters
for these databases all have custom transaction handling which
needed to be modified to set the transaction isolation level.
Raise serialization failures/deadlocks as Sequel::SerializationFailure exceptions

This builds on the support added for the ConstraintViolation
exceptions.  Having a separate exception class for these types of
errors is beneficial as these errors can usually be worked around
just by retrying the transaction.

There is no integration test for this support.  Simulating
serialization failures when testing is prone to locking up
the testing program, and the many databases that Sequel supports
handle different types of serialization issues in different ways.
Add the :retry_on and :num_retries transaction options for automatically retrying transactions

This expands the supported added a while back for the
:disconnect=>:retry option, and generalizes it to handle other
types of errors.  For example, a UniqueConstraintViolation or
SerializationFailure exception is a prime candidate for retrying
a transaction.

I've historically been against adding this as I think it's likely
that people put non-idempotent actions in their transaction blocks.
However, the recommended course of action previously has been to
use a loop in your user code, and I think this makes for a much
nicer API.  The warnings about idempotency remain, if the user wants
to ignore them, that is their problem.

In order to avoid infinite loops, the :num_retries option has been
added, and defaults to 5 retries.  With the previous code, an
infinite loop was unlikely as not much code will repeatedly raise
a disconnection error.  However, by allowing the user to pass
an exception class, we don't want to cause an infinite loop just
because they provide a CheckConstraintViolation.  For the people
that really need an infinite loop, allow an explicit nil option
for :num_replies.
Upgrade READ UNCOMMITTED and REPEATABLE READ isolation levels on Oracle
Restore previous JDBC transaction isolation level in the JDBC transaction support

This should fix issues for databases where the isolation level for
the connection persists outside the transaction in which it is set.
Disallow use of :disconnect=>:retry and :retry_on options in same transaction

In the future I want to eliminate the :disconnect=>:retry option
in favor of the :retry_on option, so I don't want to support mixed
use now.