Add spec to schema_dumper that highlight a bug

-Non autoincrementable db_types (ie char or varchar) seems to not be
well manage by schema_dumper when columns are primary_key and/or
foreigne_key
-I added 2 tests that highlight the wrong behaviour
Use explicit type for non integer foreign keys in the schema_dumper

If a type isn't specified, it will default to integer, so be sure
to explicitly specify it if the type is non-integer.

While here, change Database#schema_autoincrementing_primary_key?
to default to only looking for integer keys.  All of the existing
adapters that override it do the same thing, so it should be done
by default.

Cleanup specs from dedesite's commit to reflect the new expected
output.
Fix typo in association_basics.rdoc
Change the way we push column information from schema to a Schema::Generator
object. This enables more than one method call on the generator per column.
No other functional change intended. For the sake of corectness, adjust
method name and description appropriately.
Add "check column >=0" constraint to the dump for unsigned integer columns.
Amend the schema_dumper spec with 'check' constraints for unsigned integer columns.
Let's only load the eval_inspect extension if we need it for the constraint handling.
Significant changes to associations internals

This commit makes it possible to create associations that depend on
expressions beyond simple column references, without creating a
fully custom association (with :dataset and :eager_loader options).
For example, if you are storing one or both of the keys needed for
the association in a PostgreSQL array or hstore column, this commit
will allow you to create an association for such a relationship
without using a fully custom association.

The major new addition here is the :predicate_key association
option, which if given, is used directly by the :dataset and
:eager_loader options.  Previously, there was a similar but
undocumented :eager_loader_predicate_key that was just used by
the eager loading code.  I've added backwards compatibility if
that option is given.

The significant backwards incompatible change has to do with the
:key_hash entry in the hash passed to the :eager_loader option.
Before, this hash was keyed on column symbols and contained column
values (using Model#[]), but it is now keyed on method symbols and
contains method values (using Model#send).  This can cause breakage
in three ways:

1) The :eager_loader_key was explicitly specified to the column
   symbol as the method symbol conflicts with a ruby method name.
   Such associations should be updated to use the appropriate
   :key_method or :primary_key_method option, and should not
   specify an explicit :eager_loader_key.

2) Model#[] never raises an error if the column doesn't exist, it
   just returns nil.  Model#send raises an error if the method
   doesn't exist.  So a previously working custom association that
   didn't need the keys could now break when eager loading.  Such
   associations should be updated to specify :eager_loader_key=>nil
   if they don't need a valid key.

3) Custom eager loaders where the column symbol differs from the
   method symbol, which looked in the key_hash for the column
   symbol, would now get a nil value instead of the hash, since
   key_hash is keyed differently.  Such associations should change
   their :eager_loader option so that instead of doing
   id_map = opts[:key_hash][:column_symbol], they do
   id_map = opts[:id_map].  The :id_map option was added to the hash
   passed to the :eager_loader proc, so that custom associations
   no longer need to look in the :key_hash option.  The :key_hash
   option is still kept for backwards compatibility.

A column symbol was originally used as using a method symbol broke
code for some associations (where column names conflicted with
existing ruby method names).  However, since the support for the
column naming conflict options (e.g. :key_method,
:primary_key_method) was added back in January, this shouldn't be a
problem, as the method symbol should now work if the association is
correctly defined.

Other changes:

* The :eager_loader_key option is now set automatically be the
  association creation methods, so the related association
  reflection method no longer needs to use checked_fetch at run time.

* The predicate_keys association reflection method is added which
  caches the array version of the predicate keys, so fewer arrays
  are generated at runtime.

* The eager_loader_predicate_key association reflection method now
  is just an alias to the predicate keys method, and it is only for
  backwards compatibility, as callers have been switched to use
  predicate key.

* The Dataset#eager_load method internals have changed, and it
  now populates the key_hash entry and eagerly loads associations one
  at a time.  Previously, it populated the key_hash for all
  associations first, then eagerly loaded all associations.  This
  could theoretically cause problems if custom eager loaders were
  expecting entries in the key_hash for columns that this association
  did not currently use, but were used by later associations being
  eagerly loaded by the same dataset.

* To test some crazy associations, the postgres adapter spec now
  has tests where the associated keys are stored in hstores, to make
  sure that those type of associations can work with the
  :predicate_key and :graph_only_conditions options.

* Fix minor spec fallout from this, either setting
  :eager_loader_key=>nil where it was previously unset, or removing
  :eager_loader_key when it was previously set to the column value,
  or adding the correct method symbols when the default ones were
  not valid.
Cleanup merge issues between the unsigned schema_dumper commit and the #502 fix commit
Fix typo in association_basics.rdoc