separate migrations from CREATE / DROP plugin

• migration usage shall support a list of already applied migrations. I suggest to store a list of file that were applied during previous migrations of the same plugin with any version. We always run migrations for some specific version of the plugin, because we have to lookup in the folder of the specific version. If we try to apply migration we shall calculate which migrations were not applied (basically we just diff lists of applied files and all migrations of the specified version) and apply those (ordering those as usual).
• add boolean parameter migrate (default - false) to install_plugin. That parameter controls if UP migrations should be run.
• add boolean parameter drop_data (default - false) to drop_plugin. That parameter controls if DOWN migrations should be run
• create new command to run UP migrations. Accepts version as required parameter. We have to run only new migrations. Command shall consider plugin version to figure out migration folder.
• create new command to run DOWN migrations. Accepts version as required parameter. We do not intend to support migration rollback for specific version so we execute all down migrations. Command shall consider plugin version to figure out migration folder.