Entity first migration-generation

## Motivation Get ready this is a big one. **TL;DL** generate migrations from entity-first approach The entity-first workflow introduced in 2.0 provides `schema-sync` for development, but there is no clear path from entities to migration files for production use. Currently, developers using entity-first must either: - Enable `schema-sync` at startup, which allows to perform live schema discovery, whic is not very suitable for production. - Manually write migration files that replicate what `sync` already knows how to compute Either way its pain. The sync engine already diffs entity definitions against the live database and produces the usually correct DLLs. That diff output is exactly what a migration file should contain, but today it can only be applied immediately and not captured. **On the side note:** this approach will make dropping during sync safe enough to be justifiable ## Proposed Solution ### (Main) CLI migration generation via entity crate binary Add function similar to `cli::run_cli(migration::Migrator).await;` used by migration crates. It would: - Connects to a database (using env or cli args) - Collects entities - Runs the sync diff engine - Writes the resulting migration into a new migration file under the migration crate This would work by adding an optional binary target to the entity crate (similar to how the migration crate already has `main.rs`). -Generating migrations in sea-orm would be kinda hard so it will we raw sql wrapped in `db.execute_raw` ### (Future) Offline diff without a live database and sea_orm migrations **First** longer-term goal is about diffing against a reconstructed schema state from the migration file chain (like Django) or using an ephemeral database (like Atlas), removing the requirement for a live database during migration generation. **Second** longterm goal is be to generate migration in seaORM syntax instead of raw SQL ## Additional Information - I will implement main myself (future - unlikely to implement). **I want to disscuss my proposal before starting.** - This is partiall inspired by **Django**, with current codebase state in mind - Generated migrations are dialect-specific since they diff against a live database - this is a known limitation