Use independent models for data migration

Prior to this change, migrations used the latest version of models. This would cause issues once there are multiple migrations affecting the same model. E.g. if a property is removed from a model and a migration is expected to run for all data still having this this property this wouldn't work if a previous migration already updated date with the new model.

To fix this issue, migrations now use their own entity models which include only the properties relevant for the migration but store all other properties in a map so they can be written back unchanged to the database.

Furthermore, database views are now directly accessed through the connector instead of relying on the repositories which cannot handle the migration-specific entity models and might also change over time.

Closes: #95 (closed)