feat!: add on_additive_change support

[eakmanrq]

Breaking explanation: This change is breaking if you currently use the dbt adapter and have models using on_schema_change where we used to not correctly mimic the behavior in the SQLMesh runtime. This is non-breaking for SQLMesh native users.

Adds the ability to control the behavior of additive changes similar to destructive changes. Has the same options as destructive.

This PR also includes two refactors to SchemaDiffer:

• The SchemaDiffer now returns the classes it creates that contains the information related to the change instead of SQLGlot Alter expressions. This makes it easier to apply logic on top of these changes like determining the type of change and extracting the columns.
• The SchemaDiffer now returns classes specific to each change type instead of a single class with an enum to differentiate. This allowed the ClusterByMixin to properly document it's change type and integrate with the changes from the SchemaDiffer. Also cleaned up some confusion around optional/required fields across the changes.

The dbt adapter is updated to use these changes. See table below for a mapping of behavior from dbt -> SQLMesh (the docs also contain this):

on_schema_change	SQLMesh on_destructive_change	SQLMesh on_additive_change
ignore	ignore	ignore
fail	error	error
append_new_columns	ignore	allow
sync_all_columns	allow	allow

Two follow up PRs are required to reach on_schema_change parity:

• append_new_columns ignores alters even if the alters are additive. This PR would consider that additive and allow the change through. So need a way for dbt adapter to configure schema differ to consider alters destructive so it can be ignored.
• on_schema_change only tracks top-level column changes while, on some engines, SQLMesh tracks nested column changes. Therefore there needs to be a way to let dbt adapter to configure SQLMesh so it doesn't do nested changes.

dbt documentation: https://docs.getdbt.com/docs/build/incremental-models#what-if-the-columns-of-my-incremental-model-change

[izeigerman]

I'm curious why do you need this cast? Isn't return type of compare_columns already a subtype?

[eakmanrq]

The differ returns TableAlterColumnOperation since everything is generates are related to column operations. Methods called using this alter_operations result refer to the base class like this:

def has_drop_alteration(alter_operations: t.List[TableAlterOperation]) -> bool:

As a result I get an error like this:

sqlmesh/core/plan/builder.py:578: error: Argument 1 to "has_drop_alteration" has incompatible type "list[TableAlterColumnOperation]"; expected "list[TableAlterOperation]"  [arg-type]
sqlmesh/core/plan/builder.py:578: note: "List" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
sqlmesh/core/plan/builder.py:578: note: Consider using "Sequence" instead, which is covariant