Change schema_dumper RDoc formatting
Use change migrations instead of up/down migrations in the schema_dumper

change migrations are simpler, and the schema_dumper only used
create_table and add_index methods inside the up block, both of
which the MigrationReverser can reverse.  It's been over a year
and a half since reversible migrations have been added, so it
should be safe to make this switch.
Raise an Error if attempting to clone an association of differing type

I've done this a few times by accident when writing specs, and the
lack of an error makes it more difficult to track down the bug
in the specs.

I don't forsee problems with this, as the previous behavior was
unlikely to be used in working code.  I supposed it's possible for
one_to_many associations to be cloned to one_to_one or vice-versa,
since they share a lot of the same properties, but I don't know if
that's something we should support.
Add a couple more association related specs after recent commits
The json library is now required when running the plugin/extension specs

Previously, the extension specs tried to handle the lack of a json
library by skipping extensions or specs, similarly to how it handles
the lack of tzinfo or nokogiri.  However, because so many extensions
and plugins require json, and json is installed on almost all ruby
installations, I've decided to just require when running the specs,
which significantly simplifies the specs.
Add pg_range_ops extension for DSL support for PostgreSQL range operators and functions

This is modeled after the pg_array_ops and pg_hstore_ops extensions.

While here, cleanup the plugins page for better consistency in the
extension descriptions.
Make casting to Date/(Time/DateTime) use date/datetime functions on SQLite

Previously, Sequel didn't have special handling of this generic
cast types.  Because of SQLite's unique type system, casting to
Date/Time/DateTime was basically the same as casting to Integer.
Using the date/datetime functions is more likely to get the
desired result, though it's obviously not perfect as SQLite
does not have native date/time types.
Switch to using :id_map instead of :key_hash

The :id_map option is much easier to understand, so remove most
of the documentation about :key_hash.  While here, remove the
description of the 3 argument form of the eager_loader proc.
That will remain supported indefinitely for backwards compatibility,
but I don't want to document it as it will encourage people to
use it.

While here, switch the identity_map and rcte_tree plugins to
use the :id_map option instead of the :key_hash option.
Remove text about limit not being supported when eager loading

By default, an eager limit strategy is used so that limits
are supported when eager loading.
Allow cloning of one_to_many to one_to_one associations and vice-versa

These associations are very similar internally, so cloning one to
the other is unlikely to cause problems.  As the integration
tests already use this, it's likely other people are as well, so
let's not break backwards compatibility.
Allow for overriding the create/alter table generators used per Database object

This extracts a couple methods to make it easy for a Database
object to use a subclass of an existing generator class, allowing
for Database-specific methods to be added to generators in
shared adapters.

While here, rename the Generator class to CreateTableGenerator,
but keep Generator as an alias for backwards compatibility.
Support exclusion constraints on PostgreSQL

I think there are probably some types of exclusion constraints
that the current DSL support cannot handle (something with
index_parameters), but I haven't seen examples so I'm not sure
how to support those yet.
Support :not_valid option when adding foreign key constraints on PostgreSQL

This supports the NOT VALID syntax when adding foreign key
constraints, and also the VALIDATE_CONSTRAINT syntax for validating
them later.  Note that because of the AlterTableGenerator's API,
there isn't a way to define NOT VALID check constraints, at least
unless we add a new method.
Do not automatically cast String to text in pg_auto_parameterize extension

The default type for literal strings on PostgreSQL is unknown, not
text, so casting to text is wrong and causes more problems than
it solves.

This breaks backwards compatibility for people who are using the
extension with values and expecting the automatic casting, but
it should make it significantly easier to switch to using the
extension for people that aren't.  If you were using this
extension and this causes a problem, you just need to explicitly
add .cast(String) to the string values.