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.