[RFC] Aliases for migrations

Migrations names can't be changed after release, because it will break any installation that already applied them. This means that:

• you can never fix typo in migration name,
• you can not migrate from non-namespaced migrations to namespaced migrations,
• if you already use namespaced migration, you can never change namespace of your project or change structure of directories that can affect migrations namespaces.

Basically, migrations can be really PITA for long-term projects, especially if you decide to use namespaced migrations.

I propose to add new static property to yii\console\Migration:

namespace yii\log\migrations;

use yii\db\Migration;

class M141106185632LogInit extends Migration
{
    public static $aliases = [
        'm141106_185632_log_init', // old non-namespaced migrations
        'yii\log\migrations\M141106185632LogInt', // typo
    ];

    // ...
}

On migration/up

1. Check if any of migration aliases are already present in migration history.
2. If it is present - add current migration and all non-applied aliases to migration history with current timestamp and some prefix for name (like -), without running up() method.
3. If it's not applied - run up(), add migration (without prefix for name) and all aliases (with prefix) to history with current timestamp.

On migrate/down

1. Pick last applied migration from history.
2. If name of this migration is prefixed - remove from history without running down(). Back to step 1. (removing prefixed migration from history should not count as revert).
3. If migration does not have alias prefix in history - run down(), remove migration from history, and all related aliases (so if we're reverting m141106_185632_log_init we should also remove yii\log\migrations\M141106185632LogInit and yii\log\migrations\M141106185632LogInt from history).

Tricky part

The obvious problem is finding real migration class for an alias (if we're reverting m141106_185632_log_init we need actually revert yii\log\migrations\M141106185632LogInit). In the worst case we could scan all migrations and use $aliases values to create alias => real-class map. But usually we could avoid this - in most cases we first load a real class, so we could start building map from already loaded migrations and do a full scan only if migration to revert can not be found.

Start by locating the yii\console\Migration class and the migration/up and migrate/down entry points. Trace how migration history is read and written, then compare the proposed alias handling for applying and reverting migrations; done means aliases preserve migration history without rerunning or incorrectly reverting the real migration.