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 as well.

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.