Fix AlterField ignoring max_length changes in migrations

[Br1an67]

Description

The _alter_field method in the migration schema editor only checked for changes to nullability, index, unique, description, default, and rename. It did not compare the SQL column type, so changing max_length (e.g. VARCHAR(32) → VARCHAR(64)) produced no migration SQL and the database schema was left out of sync.

This PR adds SQL type comparison to the base schema editor and updates the MySQL, MSSQL, and Oracle overrides to emit the correct ALTER statements when the column type changes.

Motivation and Context

Fixes #2120

When a user changes max_length on a CharField and generates a migration, Tortoise correctly creates an AlterField operation. However, applying that migration does nothing because _alter_field() sees no difference in the properties it checks and returns early.

How Has This Been Tested?

Added three new tests in tests/migrations/test_schema_editor_backends.py:

• test_postgres_alter_field_max_length — verifies ALTER TABLE ... ALTER COLUMN ... TYPE VARCHAR(64) is generated
• test_mysql_alter_field_max_length — verifies ALTER TABLE ... MODIFY COLUMN ... VARCHAR(64) NULL is generated
• test_mssql_alter_field_max_length — verifies ALTER TABLE ... ALTER COLUMN ... VARCHAR(64) NULL is generated

All existing schema editor tests continue to pass (69 total).

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added the changelog accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[codspeed-hq]

Merging this PR will not alter performance

✅ 24 untouched benchmarks

---

_{Comparing Br1an67:fix/alter-field-max-length (282fa95) with develop (314273c)}