Allow arbitrary `deconstructible` class properties to participate in migrations

[Ryan Vinzent]

In order to fully take advantage of a custom SchemaEditor class, I need to apply some model level configuration. This configuration can be implemented as a class property on the model, but during the migration, all non-Field class properties are disregarded in the dynamically constructed version of the model's state.

It would be nice if any serializable (or maybe only deconstructible) class property were also able to be included in the migration, so I could add something like this:

class MyPostgresModel(models.Model):
    postgres_options = PostgresOptions(...)

Currently, postgres_options in this case is not passed to the SchemaEditor.create_model() call during the migration, even if it is serializable. The usefulness of a custom SchemaEditor is hindered if it is unable to see this extra model configuration during migrations, as this is usually the only place that a SchemaEditor is invoked. We are already unable to add any additional Meta options, so it seems like there is not currently a natural place for extra table level configuration that can be tracked by migrations.

This could enable user-defined ModelState in migrations, and allow third-party database backends to more easily participate in the migrations framework.

[Simon Charette]

I think this is part of a larger discussion around #5793 so I'll close this one as a duplicate.

The issue here is that we not only need a way to detect these changes but also a way to keep track of them and their evolution through time. If we were to add support for custom attributes addition like #5793 proposes we'd get all of that for free as these options would be included in ModelState.options and ultimately make their way to the schema editor.