Fix creation of case insensitive indexes with non-caseable columns
* SchemaPlus::ActiveRecord::ConnectionAdapters::PostgresqlAdapter#add_index
  had issues creating case insensitive indexes if there were non-caseable
  (i.e. integer, numeric, etc.) columns that didn't end in "_id".
* I added tests to spec/schema_dumper_spec.rb for all of the Rails-defined
  non-caseable column types.  I added columns for each of these types to
  the posts table and then defined the tests for each of these columns
  using iteration.
* The code fix took more work than I initially thought.  It took me a while
  to locate the #columns method.  Although the method signature in 3.2.14
  lists a second optional parameter of 'name', it doesn't appear to do
  anything with that parameter and the parameter was removed in 4.0.0.  So
  I filter through the complete list to extract the caseable columns (I
  considered other approaches, but this one balanced out line lengths best
  without refactoring the code massively) and then use that in the test.
  Since this work is only required for case insensitive indexes, I hoisted
  the case insensitive test outside of the quoted_column_names enumeration.
* Note that this will produce a change in behavior if users have columns that
  end in "_id" and that are of type :string or :text - previously these
  columns would have been case sensitive in the index, and now they will be
  case insensitive.
* In order to get the test suite passing, I had to modify some of the
  regexes that are too strict with spaces.  I also modified them so they
  would accept both the Ruby 1.8 and 1.9 hash syntaxes (i.e. ':key => value'
  vs 'key: value') and to make them a hair more rigorous (escaping .).
First stab at getting schema_plus working with Rails 4!
* This has been tested under Rails 3.2.14 and 4.0.0 against PostgreSQL
  and SQLite3, but not against either MySQL variant.  Both tests were
  done using Ruby 2.0.0p247.
* I have not used this code in any real database - all I did was get
  the test suite passing.  I do not fully understand all the code I
  modified - there was code that I thought might be superfluous even
  under 3.2.14 relating to indexes, but I left that code in place for
  3.2.14 even though it was unnecessary for 4.0.0.
* I modified .travis.yml to test against Ruby 2.0.0 instead of 1.9.2
  (since the latter is no longer being patched and is not supported
  by Rails 4).
* I modified gemfiles/rails-4.0/Gemfile.base to point to the currently
  released version of 4.0.x rather than master.
* I added gemfiles/rails-edge (basically the same stuff that was in
  rails-4.0 before I pointed it to the released version) and adjusted
  .travis.yml to consider -edge to be the allowed failures.
* I removed the mysql tests for Rails 4 and Rails Edge in .travis.yml
  and in the gemfiles directories.  I can't find anything to back up
  my suspicion, but I suspect that mysql support was removed from
  Rails 4 in favor of mysql2.

The changes were all Rails 4 vs Rails 3 changes and are all toggled
on and off by testing ActiveRecord::VERSION::MAJOR.to_i.
* TableDefinition#indexes returns a list of index objects in Rails 3.
  It appears that in Rails 4 it should now return a Hash keyed on
  column_name (which may be a single column name or an Array of
  column names) with values that are options hashes.  All references
  to @indexes in active_record/connection_adapters/table_definition.rb
  were modified to assume an Array for Rails 3 and a Hash for Rails 4.
  These were #initialize_with_schema_plus, #index, and #index_exists?.
* The above change also affected SchemaPlus::ActiveRecord::
  ConnectionAdapters::SchemaStatements#create_table_with_schema_plus.
  Since indexes no longer returns an array, the code to create the
  arrays was impacted.  However, I'm not sure if this wrapper code
  is still necessary in Rails 4, since the indexes appear to be
  created by the original #create_table method without any problem.
  I left the existing Rails 3 indexes code in this method in place
  wrapped in version test conditionals.
* In Rails 4, ::TableDefinition#to_sql is no more!  The whole table
  creation approach has changed dramatically, and now uses a visitor
  pattern based around ::SchemaCreation#visit_TableDefinition.
  Unfortunately, this new approach does not have as clean a cut
  point, and I'm not going to try to drive changes in ActiveRecord,
  so I did the best I could.  The new visit_TableDefinition method
  chain calls the existing method and then verifies that the last
  chunk of the returned SQL matches the expected last chunk before
  inserting the foreign keys before the last chunk starts.  I could
  have simply replaced the entire upstream method, but that means
  that upstream fixes might not make it through.  This approach should
  fail with an informative message if the upstream fixes affect the
  logic, which is preferable to silent mangling.
* The above change required adding an attr_reader for :foreign_keys in
  ::TableDefinition.  SchemaPlus.insert_connection_adapters was
  modified to insert the new SchemaPlus::...::SchemaCreation module
  into the ActiveRecord::...::SchemaCreation module on Rails 4.
* A refactoring of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter
  moved #indexes into ::SchemaStatements.  I'm not sure why the code in
  SchemaPlus::ActiveRecord::ConnectionAdapters::PostgresqlAdapter.included
  strips the #indexes method (it gets replaced later in the codebase),
  but I added a Rails 4 variant that strips it from the new location.
* The module name for the SQLite adapter changed in Rails 4 - it is
  now SQLite3 instead of SQLite, so the SQLite3Adapter was modified
  to send to the new class name for Rails 4.
* Rails 4 uses the AbstractMysqlAdapter class to handle variations
  from the AbstractAdapter class for MySQL.  In particular, this class
  completely replaces #add_index in order to eliminate features that are
  unsupported in MySQL.  Which means that the schema_plus extensions
  to #add_index to trap errors that would otherwise be raised never
  gets called.  So the alias_method_chain for #add_index needs to be
  called on AbstractMysqlAdapter as well.  To facilitate this,
  SchemaPlus::ActiveRecord::ConnectionAdapters::SchemaStatements::AddIndex
  was extracted from ::SchemaStatements.  To get it lodged into the
  appropriate adapter class, an include for it is embedded in
  SchemaPlus::ActiveRecord::ConnectionAdapters::MysqlAdapter.included.
Merge pull request #115 from tovodeverett/rails4

First stab at getting schema_plus working with Rails 4