update JDBC driver loading to handle latest jdbc gems
latest gems no longer auto-load the driver jar but instead provide a load_driver method, this change is handled backward compatible (since not all driver gems are updated + users might decide to stick with an older gem version).
Attempt to use the jdbc-hsqldb driver if available

Sequel only supports HSQLDB 2.2+.  Previously, the jdbc-hsqldb
gem was at version 1.8.1.3.  However, it has recently been upgraded
to 2.2.9, and Sequel now supports it, so load it automatically
so that the jar does not need to be loaded manually.
Allow treating tinyint(1) unsigned columns as booleans in the mysql adapters

Previously, the schema type for tinyint(1) unsigned columns would
be integer instead of boolean.
Add some warnings to the documentation related to Object#extend use

Object#extend busts method caches in MRI and probably other current
ruby implementations, so note usage in the documentation so that
users can be aware of it.
Support default_schema when reseting primary key sequences on PostgreSQL (Fixes #596)
Handle schema-qualified row_types in the pg_array integration in the pg_row extension (Fixes #595)

This isn't a bulletproof fix, but it does fix the issue in most
cases.  A more complete fix would handle quoting of the type
names.
Allow lambda procs with 0 arity as virtual row blocks on ruby 1.9

Previously, such blocks did not work, because the blocks would be
instance_evaled, which passes an argument, and lambda procs with
0 arity would raise an error in that circumstance on ruby 1.9+.

Now that Sequel no longer supports ruby 1.8.6, switch from
instance_eval to instance_exec, making such procs work.

For compatibility with ruby 1.8.7, make Sequel::BasicObject
respond to instance_exec on ruby <1.9.
Define respond_to_missing? where method_missing is defined and the object supports respond_to?

There are a couple of other places in Sequel where method_missing
is used, but those places do not support respond_to?, so defining
respond_to_missing? doesn't make sense for them.
Make Database#copy_into raise a DatabaseError if the database signals an error in the postgres adapter

Previously, such errors were swallowed by accident.
Bump copyright year
Remove the _*_dataset_helper private method definition

This private method existed because when association support was
originally added to Sequel, instance_exec was not supported, so
the only way to pass arguments to an instance_evaled block was
to define a method for it.  Now that Sequel has dropped Ruby
1.8.6 support, all versions of ruby supported by Sequel support
instance_exec, so just use that instead.

The public AssociationReflection#dataset_helper_method is also
being removed, since it no longer has any use.
Optimize some #hash definitions

When Sequel supported ruby 1.8.6, it had to transform hashes to
sorted arrays inside #hash, since in ruby  1.8.6, Hash#hash is
different for two hashes even if they are equal according to ==.

Starting at ruby 1.8.7, Hash#hash is the same for hashes equal
according to ==, so we no longer need to create the sorted array,
which should make these #hash definitions faster.
Add core_refinements extension, providing refinement versions of Sequel's core extensions
Fix Database#copy_into on jdbc/postgres when an exception is raised

The previous implementation has a serious error in that if a ruby
exception was raised, it committed the copy instead of aborting
it.  The reason this wasn't caught by the specs is that it used
an internal transaction.  However, the method is not specced to
use an internal transaction, and the native postgres adapter does
not use an internal transaction, so remove the transaction usage.
In addition to aborting the copy correctly, also correctly wrap
the underlying exception in a DatabaseError.
Remove remaining use of meta_def from lib code
Remove meta_def usage from the model and adapter specs
Move the #meta_def support for Database, Dataset, and Model to the meta_def extension

This is a backwards incompatible change in that the #meta_def
method is no longer available by default on Database, Dataset,
and Model classes and instances.

Sequel originally depended on the metaid gem that added meta_def
and a handful of other methods to Object.  Over the years I removed
usage of most of the other methods, and restricted their definitions
in Sequel to just Database, Dataset, and Model classes and instances.
However, the metadef method was only used in a couple of places
in Sequel, and it really only saves a few characters in those
places, so I decided to remove usage of meta_def completely.

As meta_def was no longer used internally, and it was originally
only used for implementing Sequel, there was no need to load it
by default and have all Sequel users pay the memory penalty for
it.

Since some users may need it, I've decided to move it to an
extension to make it easy to work with old code.

The core and extension specs still use meta_def significantly, so
the extension is loaded automatically by those specs.  Hopefully
those specs can be cleaned up in the future.
Bump version to 3.43.0
Improve association method performance by caching intermediate dataset

Previously, when getting an association dataset, it would always be
derived from the associated class, which can be an expensive
operation due to the number of dataset clones involved.  Additionally,
all association datasets are extended with a module, which resulted
in Object#extend being called at runtime, leading to a performance
decrease as method caches are cleared.

This commit starts caching the non-instance specific dataset in
the association reflection, so that when an instance requests a
an association dataset, much less work is necessary.

This increases association_dataset method performance by about 179%
and association method performance by about 29% on ruby 1.9 in my
testing.  However, that performance increase only affects
associations without a custom :dataset option.  Associations with a
custom dataset option are marginally slower with the new code.

This change should not have backwards compatibility issues, since
it only affects datasets without custom dataset options, and the
standard association dataset just uses filters/joins.  The spec
changes are just for reordering of conditions, since the
:conditions option is now applied to the dataset before the
foreign key filters.

While here, switch from using filter to where, since we always want
to affect the WHERE clause with association conditions.
Document that the eager_each plugin uses Object#extend at runtime