Add auto_validations plugin, for automatically adding presence, not_string, and unique validations

This plugin is mainly useful if you want to easily add common
validations that can be determined from the model schema, and
do not care about using custom validation messages per column.
Skip validates_unique validation if underlying columns are not valid

If the underlying columns are not valid, the database query to
determine uniqueness could raise an error (for example, an integer
column not in integer format).  That defeats the purpose of
attempting to validate first, so skipping the uniqueness check is
probably best.  The model object is going to be considered invalid
anyway, so the only behavior change other than not raising the
error is that there will be no errors entry for the uniqueness
validation in some cases.
Add error_splitter plugin, for splitting multi-column errors into separate errors per column

This makes it easy to use the auto_validations plugin to
automatically add multi-column uniqueness checks, and have
validation error handling code automatically be able to
associate the uniqueness error with each related column
(e.g. highlighting all appropriate fields on a web form).
Add Database#schema_type_class for getting the ruby class or classes related to the type symbol

This can be used to automatically validate model instance column
values against the appropriate schema type.
Allow validates_type validation to accept an array of allowable classes

There are some cases where multiple classes would be valid for a
given column.  The most obvious is boolean columns, which can be
either TrueClass or FalseClass.

While here, slightly change the default validates_type message.
Before, this used a capital class name, but that is inconsistent
with the rest of the messages.  Now it uses a lowercase name.
Add Model#schema_type_class for getting the class for given column's type

Not used internally by the core yet, but will be useful for plugins.
Add validates_schema_types validation for validating column values are instances of an appropriate class

Previously, one of the recommended approaches for dealing with invalid
input with Sequel in web applications was to use the not_string
validation in combination with raise_on_typecast_failure = false.
The idea behind this is that invalid input comes in the form of a
string, so you could use this on non-string types to validate that
the value was typecast correctly.

Unfortunately, while this works in most cases, it is a flawed
approach.  First of all, web application input can also come in the
form of a hash or array (default rack param parsing), and the
not_string validation wouldn't catch that.  Second, you can't use
the not_string validation for string or blob columns, so it isn't
generally applicable.

This new approach uses the database schema information in combination
with the recently added schema_type_class method to get the
appropriate ruby class for a given schema type symbol, and check
that the column value is an instance of that class.

This should be safe to use for all model instances.  Unhandled
database types won't be affected, nor will database types that
have no appropriate ruby class (such as enum).  Every column type
with a handled type class should have a value that is an instance
of the related type, assuming that typecasting works correctly.

The only time this will cause problems is if the database does
not return correctly typecasted values, in which case you'll want
to use the typecast_on_load plugin.
Switch auto_validations plugin to use a type validation instead of a not_string validation

Validating by type is a more robust approach, and handles all of
the columns instead of just the non-string ones.  The previous
code didn't correctly handle unrecognized types (such as PostgreSQL
intervals).
Make Postgres::HStoreOp#- explicitly cast a string argument to text, to avoid PostgreSQL assuming it is an hstore

PostgresSQL has two different - function/operators on hstore,
one for text and one for hstore.  However, if an explicit cast
is not used, the type is unknown, and PostgreSQL gives higher
precedence to the function that accepts an hstore.  As the
string is probably not in hstore format, this usually results
in an "Unexpected end of string" error from the database.