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.