avoid using model classes in Alembic migrations
    
    ... otherwise we can never change or remove the columns used in the
    migrations. The migrations need to use raw SQL and so-called
    "lightweight" table definitions for interacting with the database
    instead, according to the state of the schema at the point in time the
    migration was written for.
    
    This fixes migration 71b84ccc31bb (result_id -> subject, testcase)
    allowing us to drop the result_id column from the model definition. It
    will also allow us to write further migrations in future to change/drop
    the subject column.