Refactoring migrations

[doekenorg]

• Added a Repository for the migration to provide a simpler (more testable) API, instead of coupling it directly to WordPress; making it simpler to change the implementation of retrieving migrations later on (use a file or array for example).
• Optimized filtering of migration that should be run, by static $version and via is_subclass_of, to prevent instantiating of unused migrations.
• Changed the logic of storing the last version of the last migration, to storing the last plugin version. Which now allows us to check if we should run migrations, based on the current plugin version; and the last version we ran migrations for.
• Moved running of migrations to init_admin to ensure the front-end wil not trigger a migration. This also removes the issue of updating the plugin by hand instead of the normal update process.
• Added error logging of migration through the GravityExportAddon::error_log. Did this so we can later simply update this method to call the Foundation logger.

[rafaehlers]

@doekenorg do I need to test something here, or do you just need a code review?

[doekenorg]

@doekenorg do I need to test something here, or do you just need a code review?

Both if possible. The thing to test would be if settings are properly ported from 1.* to this new version. In this version the plugin is a feed plugin, and not a regular plugin anymore. Therefore all the current settings should be moved towards this new addon without breaking the download url.