Make it easier to change migrations in development

[pcaisse]

Detailed Description/Context

Currently, the "happy path" workflow for adding a new migration is straightforward:

1. Make changes to an entity that would necessitate a migration
2. Run ./scripts/yarn server migration:generate to generate the new migration, determining what changes are necessary based on changes to the entity
3. Run ./scripts/migration to apply the migration to your development database

However, if you need to make further changes to a migration after you've generated it -- eg. rename a field, add a missing constraint -- without wanting to generate a new migration for just that change, that's where things get weird. If you want a totally new migration you need to first:

1. Revert the applied migration that you want to change if needed (this makes sense)
2. Delete the auto-generated migration (this makes sense)
3. Delete the dist files generated for the migration you want to edit (path is configured in ormconfig.js, currently src/server/dist/server/migrations/).

This is because the files within dist are what typeorm actually uses to know what should happen to your database.

Alternatives/Possible Solutions

To work around it, we could:

1. Never update a migration and just keep creating new ones. The downside to this is there will potentially be a bunch of artifact migrations that reflect intermediate steps in the development process, perhaps akin to unsquashed commits, except they could actually impact production.
2. Create migrations by hand or edit existing migrations by hand (this seems error prone)

To mitigate/solve it:

1. Document deleting files in the dist directory
2. Create some scripts/tooling for updating a migration more seamlessly in development
3. Maybe there's a better way to handle this ???

[maurizi]

I think after looking into this a bit recently, we could switch to using ts-node to run migrations, so it would use the TypeScript files instead of the compiled JS files, which would make this a bit less painful.

Not sure if that would have any implications on running migrations in staging / production; I'm fairly certain we ship .ts files even if we only run the compiled .js files normally, but it would be important to test before making such a change.