Some SQLMesh versions introduce breaking changes that cannot be fully handled by simply manipulating state. These upgrades typically require users to update their project definition and apply a plan to complete the migration process. Without doing so, cadence runs may start failing after the upgrade, and applying a plan becomes necessary to restore normal operation.

The problem is that we currently have no way to inform the user that this additional step is required. The best we can do is issue a warning during the migration process (example), which is already too late. Users don’t get a chance to prepare for such a breaking upgrade and are forced to to fix their project ASAP or resort to rolling back their state.

This PR aims to address the above problem by introducing a new concept: pre-checks. These are scripts that correspond to a particular migration script and contain a single function pre_check.

The pre_check function's only purpose is to inspect the current state and determine whether the project will require a plan application after the migration is complete. It returns a list of messages that will be shown to the user, explaining any necessary changes on their end and outlining the steps they need to take.

It’s the responsibility of the developer introducing the breaking change to implement the pre_check function, in addition to the migrate function, when applicable.