refactor(database)!: improve make:migration experience

[xHeaven]

The followings are now possible:

# Interactive Q&A about migration name, type, table (predicted), alter (predicted), and filename
./tempest make:migration

# Interactive Q&A about migration type, table (predicted), alter (predicted), and filename
./tempest make:migration "create books table"

# Interactive Q&A about migration table (predicted), alter (predicted), and filename
./tempest make:migration "create books table" up

# Interactive Q&A about migration alter (predicted), and filename
./tempest make:migration "create books table" up --table=books

# Interactive Q&A about migration alter (predicted), and filename
./tempest make:migration "create books table" up --table=books

# Interactive Q&A about migration filename
./tempest make:migration "create books table" up --table=books --alter

# Oneline migration creation with default options
# type: class
# table: predicted (in this case "books")
# alter: predicted (in this case: false)
# filename: in this case CreateBooksTable.php
./tempest make:migration "create books table" -y

The table name and alter are also predicted (as mentioned above).

For the $alter feature, the guesser is expecting a create keyword as the first word, if that appears, it will predict true, a create migration. If not, then we are looking for prepositions (_to_, _from_, _in_), if any of those exist, we predict false, an alter migration. If none of those exists, we fall back to true, a create migration.

For the table name prediction, the guesser follows the same rules: if the migration starts with a create keyword, we strip create_ and the optional _table suffix, and use what remains as the table name (in this case: books). If not, then we are looking for prepositions (_to_, _from_, _in_), and if any of those exist, we take everything after the last preposition, strip the optional _table suffix, and use that as the table name. If none of those exists, we fall back to using the full migration name as the table name candidate, and then normalize it to get the final table name.

The command also takes NamingStrategy and MigrationNamingStrategy into account when creating the final table name.

[brendt]

My bad on not merging this before tagging 3.0, because the MigrationPrefixStrategy rename is a breaking change.

Not too big a deal though, but maybe we should just revert it back to the original name?

Then we could rename it as part of 4.0

[xHeaven]

My bad on not merging this before tagging 3.0, because the MigrationPrefixStrategy rename is a breaking change.

Not too big a deal though, but maybe we should just revert it back to the original name?

Then we could rename it as part of 4.0

Yeah, I can do that. I'll push a commit in a few minutes.

[xHeaven]

There it is.

/