Integrate morph into the plugin

[mgdelacroix]

Summary

This PR integrates morph into the plugin store code, moving all migrations to SQL files, splitting them for improved clarity and structure. It creates a new msteamssync_system_settings table that stores one row per data migration, allowing them to indicate when they've run and removing the need for checking the database status every time the plugin starts to see if each data migration should run.

The Migrate method implements a sequence of migrations that ensures that at every step all the requirements of the next migration are met or checked (either by morph or the data migration through the previously mentioned table), and every step logs when the migration starts, stops and the elapsed time.

[mgdelacroix]

@lieut-data we could do one big "init" migration only, but there are two downsides that I can think of:

• There are some data migrations that can only run in an intermediate state, I'm thinking specifically on the whitelisted_users data migration, that we run just before migration 14, which deletes the table. We could have two steps then, or ask current plugin users to follow an update plan (so they update to the last version before morph, run the plugin and then update to the first version including it, for example), but that's added complexity.
• The migration will run as a single big transaction for instances that already have the plugin installed. The queries are thought to be no-ops for the current last version of the plugin's database, but if something unexpected happens, I think we'd be in a better situation having small steps to rollback and rerun.

[mgdelacroix]

/update-branch