Move upgrade path into migrations

*As discussed at the end of #19*

This removes the upgrade path from the install generator in favor of moving that functionality into the migrations by adding a new migration that reproduces the original CASinoCore schema.

This allows `casino:install:migrations` to work for both CASino 1.x as well as completely clean installs.
    
Under a clean install, this new migration will create all of the CASino database tables with the older CASinoCore names. These will then be renamed by the "upgrade" migration.
    
Under a CASino 1.x install, this new migration will do nothing because the tables already exist. The upgrade migration will then handle renaming all of the tables.
    
When rolling back, the upgrade migration will go ahead and drop all of the CASino tables and indices. This is because there is no programmatic way to determine whether the migration ran with the context of a prior install or a clean install.

The only issue I ran into is that the migration added [here](https://github.com/rbCAS/CASino/blob/61c97fadd094225de56f263b65e961551789c86c/db/migrate/20131022110146_cleanup_indexes.rb) does not provide a `down` path when rolling back. This raises a `ActiveRecord::IrreversibleMigration` because ActiveRecord cannot determine what action to persue.

I would recommend maybe merging those last minute migrations into the migration that actually creates them. This keeps the migrations that are installed clean and concise. Since 2.0 hasn't been released yet, now would be the time to do it.