Support :correlated_subquery as an eager_graph and filter by associations limit strategy for one_to_* associations

Sequel used to have a correlated_subquery approach for regular
eager loading, but that was removed in 4.0.  This uses a similar
approach for eager_graph and filter by associations.

In my testing I have found that the correlated subquery strategy
is fastest in some cases for eager_graph and filter by
associations.  This is usually when you are selecting a small
number of current records out of a large table of current
records, and the number of associated records for each current
record isn't too large.

I have no plans to add support for using correlated subqueries for
regular eager loading, as the current union approach is always
faster in my testing.

As the only previous filter by associations limit strategies were
distinct_on and window_function, filtering by limited associations
didn't work on databases that don't support window functions. This
commit allows them to work on such databases.

There are a couple cases where the correlated subquery strategy
won't work correctly. One is when you are using MySQL, which doesn't
allow LIMIT clauses inside subqueries passed to IN.  The other is
when you are using composite primary keys and the database doesn't
support multiple columns in IN, since in that case Sequel has to
emulate the IN using a separate query, and that doesn't work
for correlated subqueries.

Currently, the correlated_subquery strategy is only supported for
one_to_one and one_to_many, and probably only works correctly if
you are not using qualified identifiers when filtering or ordering
the association.  It is possible to handle other association types
and automatically requalify qualified identifiers, but I don't
plan on implementing that unless I get a request for it, as those
are significantly more complex.
Avoid bad SQL when emulating offsets on Access with placeholder literal arguments

Note that this just avoids an invalid SQL query, the resulting
query is probably still wrong as this probably results in an
inaccurate count.
Add Dataset#supports_limits_in_subqueries? and #offset_requires_count?

This allows us not to test for specific database types in the code
and specs.  The supports_limits_in_subqueries? replaces a specific
check for MySQL.  The offset_requires_count? checks are new, and
avoid using a UNION or correlated subquery approach automatically
on Access when the association uses an offset.
Add spec for eager loading for many objects

I don't think the existing integration tests handle testing eager
loading with a large number of objects, so this is a good test
to have.
Replace Dataset#offset_requires_count? with #supports_offsets_in_correlated_subqueries?

It looks like offsets in correlated subqueries don't work in any
case where the offsets are emulated.  This is true both when
a count is used (Access), and also when row_number is used to
emulate, as the query to get the columns to use fails in that
case due to the correlation not being present.

This means that the correlated_subquery limit strategy is not going
to work in cases where an offset is used and the database emulates
offsets, so manually skip those specs.
Add :server_version Database option on Microsoft SQL Server, instead of querying the database for it
Make active_model plugin spec work with new minitest
Remove jdbc/sqlite spec guard for savepoints
Add Database#transaction :auto_savepoint option, for automatically using a savepoint in nested transactions

This is most useful when testing, where the test runner can use
the option, which ensures that rollbacks for internal transactions
still work correctly.

Unfortunately, this required some refactoring of the transaction
code, and it breaks backwards compatibility with any custom
adapters that use the :savepoint_level or :savepoints transaction
hash entry.  Instead of doing _trans(conn)[:savepoint_level], users
should switch to savepoint_level(conn).  The savepoint level
is set/modified in add_transaction and not begin_transaction now,
which should be easier for custom adapters.
Rename Dataset#supports_limits_in_subqueries? to #supports_limits_in_correlated_subqueries?

This renames the feature check and sets it to false on Oracle.
On Oracle, correlated subqueries with limits are not allowed,
because the limit must be emulated with ROWNUM and an additional
subquery, and correlations only look up a single level on Oracle
(per the SQL standard).