Make the primary key to use for the migration configurable

[ags]

This a squashed and rebased version of #49, since @airhorns seems unreachable.
There were a few conflicts, which I've resolved. It'd be great if we can get this looked at again!

---

#49

Instead of relying on a table to have a primary key, we now accept the
order_column option and put that everywhere. This kind of uncomfortable
state about the migration now needs to be given to everyone and I think
an appropriate place is the migration, since most objects in the system
have access to it and they all need to agree on the value. This required
passing the options down a couple more objects for the Migrator creating
the Migration to have access, but I think thats acceptable for this
increase in functionality.

[iamliamnorton]

Nice work @ags, hopefully this gets merged soon.

[arthurnn]

@ags thanks for the PR, do you mind rebasing this against latest master and add a changelog entry for it?
thanks

[mockra]

Sorry for the bump, but any idea if/when this will be merged? Thanks!

[mockra]

There's no way for this to not error out when an order_column is specified.

@origin.satisfies_id_autoincrement_requirement? checks the id column, even if an order_column is set. Once that check fails, an error is set no matter what. The code should probably look more like:

      if @options[:order_column]
        if !@origin.can_use_order_column?(@options[:order_column])
          error("origin does not satisfy primary key requirements")
        end
      else
        if !@origin.satisfies_id_autoincrement_requirement?
          error("origin does not satisfy primary key requirements")
        end
      end

Sorry for the comment, not sure what the best way to submit changes to a PR is. Thanks!