Integration test the pg_array_associations when using the jdbc/postgresql adapter

Originally jdbc/postgresql did not transparently handle the columns,
but that was fixed a few versions back, so enable support for it.
Add AssociationReflection#cloneable? to abstract cloneability test

Previously, there were hard coded exceptions for one_to_many and
one_to_one, this makes it possible for custom association types to
define what association types they are cloneable from.
Add one_through_one association, similar to many_to_many but only returning a single record

This is most useful if you are dealing with a schema with
a join table between the current model table and the associated
model table, but where the join table has a unique constraint
on the foreign key referencing the current table, so there is
a true one-to-one relationship between the current model and
the associated model.

This is similar to ActiveRecord's has_one :through option,
assuming a single join table.

While this association is not needing all that often, it's
being included by default as it only requires minor changes
to the many_to_many code to implement.
Add :graph_order association option, useful when :order needs to contain qualified identifiers

If :order contains qualified identifiers, there will always be cases
where eager_graph can break, such as when the table is automatically
aliased multiple times.  In such cases, you can continue using :order
with qualified identifiers, but use :graph_order with unqualified
identifiers, since eager_graph will automatically qualify such
identifiers for you with the appropriate alias for the table.
Add one_through_many association to many_through_many plugin, for only returning a single record

This basically an extension of the changes for many_to_many ->
one_through_one applied to the many_through_many association.
Like one_through_one, it handles the case where all foreign keys
referencing back to the current table are unique, or cases where
where you want to use an order and only return the first
associated row.

While here, fix the cloneable? checks in association reflection
so that you can't clone many_to_many to many_through_many.
Rename web page templates to have .html.erb extension
Support distinct_on eager limit strategy for one_through_* associations
DRY up some shared association reflection code using a module
Add AssociationReflection#initialize_association_cache to DRY up some code
DRY up some more eager loading code

This moves apply_window_function_eager_limit_strategy from being
a private class method to being an association reflection method.

It also changes the initialize_associations_cache method just
added to only take the rows, since it can now determine whether to
use an array or not by introspection.
DRY up eager loading code for ruby eager limit strategy
Change guards for core_refinements spec

respond_to?(:using) apparently does not work.
Fix eager limit strategy used for pg_array_associations

These have always implicitly used the window function strategy,
but their eager_loaders just assumed the ruby strategy if there
was a limit.  Just set the strategy to ruby if there is a limit
so the existing code works.
Add documentation about the interaction between various pg_* extensions
Add examples showing class inheritance to the inheritance plugins
Add association_join to model datasets, for setting up joins based on associations

There have been many requests for this type of functionality in the
past, but I could never think of a good name for it.  I've given up
on a good name, so association_join it is.

Implementation is fairly simple, piggy-backing on the eager_graph
support, and just copying the resulting JOIN.  Only a couple new
features were needed:

1) Making the default eager_grapher procs respect a passed in
:eager_graph :join_type option and override the one used for the
association.

2) Making Dataset#graph not use a from_self in cases, as otherwise
using separate association_join calls doesn't work (since the
:graph/:eager_graph metadata is retained across calls).
Respect offsets when eager graphing *_one associations

Previously these were respected by eager, but not by eager graph,
resulting in incorrect values if they were used with eager_graph.
Handle presence validations on foreign keys in associated objects when creating new associated objects in the nested_attributes plugin

If you have a presence validation on a foreign key in the associated
object, it would previously fail when using nested attributes, because
all validations are done before the parent object is saved, and the
foreign key value is not available until after the parent object is
saved (if the parent object is also a new object).

Handle this case by assigning the foreign key value for the
associated object before validation, and if the parent object doesn't
have a primary key, setting it to a dummy zero value.  If a dummy value
is used, it is removed after validation to avoid issues if the save
isn't successful.
Make Database#register_array_type work without existing scalar conversion proc in the pg_array extension

The previous code was too strict.  A missing conversion proc is an
optimization for the case of a conversion proc that returns the
argument unmodified, so it shouldn't cause an error to be raised.
Handle offsets on *_many associations when eager graphing when there are no associated results