Better handling of database migrations

In order to ease upgrades, database migrations must be handled by the application and not rely on external SQL migration scripts. This will be split in several sub-tasks as it is huge work :

• #211 (closed) Add a migrate module:
  • Collects migrations
  • apply migrations or rollbacks as needed
  • Add a table to store migrations status
• CLI modifications:
  • #213 Add a command db init [--print] [--dry-run] to initialize the database
  • #212 (closed) Add a command db migrate {up|down} [--to=] [--dry-run] to migrate or rollback the database (the --to option allows the user to specify a version.
  • #219 Add a --print option to db migrate commands
  • #214 Add a command db status [--short] to check the status (applied migrations, migrations to apply, version of the database model)
  • #213 Deprecate the command db dump as it is replaced by db init
• #215 Add an option [db].AutoMigrate to allow Waarp Manager to automatically apply migrate in the start sequence (defaults to false for retro-compatibility)
• Modifications to the start sequence:
  • #215 If auto-migrate is enabled, run the migrations and exit on error
  • #216 (closed) If auto-migrate is disabled, and the model is not up-to-date, exit with an error.
  • #220 (closed) Collects migrations from model at start