Use a UNION-based strategy by default to eagerly load limited associations

This switches the default strategy for eager loading limited
associations to use a UNION-based strategy instead of the
previous DISTINCT ON/ROW_NUMBER-based strategies.  In extensive
testing, I've found this to be the fastest strategy assuming
the table is indexed appropriately.  It is unfortunately much
slower if the table is not indexed appropriately, but if you
don't index your tables appropriately, it's unlikely you care
much about performance.

This requires some restructuring of the eager loading code,
since previous eager limit strategies just added a filter to
an unlimited dataset, and the UNION-based strategy requires a
different approach.

The basic idea behind the UNION-based strategy is simple, you
just take the queries that would load the associations lazily,
and you UNION them together.  It's faster than the other strategies
as the other strategies all process rows after the limit for the
association, while the UNION strategy does not need to process
those rows.  The previous strategies could actually be much slower
than lazily loading if the database was running on the same host
as the application.

In my testing, the UNION strategy gets slower the number of
subqueries inside a UNION query, but decreasing the number of
subqueries increases the total number of UNION queries, so the
optimum value depends on the latency between the database and
the application.  Additionally, some databases refuse to
evaluate UNION queries with too many subqueries.  Sequel sets
a default of 40 subqueries per union, which users can increase
or decrease on a per-association basis via the :subqueries_per_union
option.

As a UNION-based approach cannot be used for eager_graph or
filtering by associations, choosing the correct strategy for
those has changed somewhat.  A :filter_limit_strategy has been
added for specifying the limit strategy to use when filtering
by associations, instead of always using the eager limit
strategy.

While here, I've moved the eager loader for many_*_many associations
into the reflection object, so it can be shared by both many_to_many
and many_through_many.

I've also pulled out the Dataset#eager argument handling into
a separate method, as it needs to be reused by the UNION-based
eager loader without calling Dataset#eager.
Handle placeholder literal values when emulating offsets with row_number

When emulating offsets with row_number, we need to get the columns
for the dataset in order to construct the SQL for the dataset. This
is a little bit of a chicken and egg issue, since getting the columns
requires constructing SQL related to the dataset.  With the previous
code, the code to generate the columns would fail, since it wouldn't
have a value for the placeholder.  This works around that by using
NULL for the value.
Don't emulate offsets if the dataset uses literal SQL
Handle placeholder literalizer arguments on Oracle when emulating offsets
Add specs for Database#execute_{dui,ddl,insert}
Squashed commit of call_mssql_sproc named parameters support

This was written by Y.Zemlyanukhin <y.zemlyanukhin@mdterra.org>
Refactor call_mssql_sproc named parameters support

This DRYs up some duplicated code, and unifies the interface for
using named output parameters and unnamed output parameters, always
using an array of [:output, type, name].