Split migration business logic code

[lxatstariongroup]

For migration, the actual migration logic should be split into classes based on the separation of concerns, something like:

• a "migrator" class responsible with the high level flow
• a "pull" abstract class, with concrete subclasses for each server type/version logic
• a "push" abstract class, with concrete subclasses for each server type/version logic

[cozminvelciu]

See Syncer\Utils\Sync for a recommended structure using the factory pattern.

Additional notes:

• MigrationViewModel
  • canExecuteMigrate can only watch for both logins success, and not the sessions
  • AddSubscriptions does not need to update Migration utility sessions every time they change; they can be set only on execute when the migration helper would be created