rebase-migration: Make it possible to handle chains of migrations.

[roanster007]

Commit 1:
Previously, the rebase_migration command was not able to rebase chains of migrations in a single app.

This commit introduces a new flag -- "--new" which basically is used for the first migration you create in a commit , and it wipes out your migration history in max_migration.txt, and writes up that first migration in the first line. Any further migrations added without the flag are simply added under each other in the max_migration.txt.

This would allow the rebase_migration command to access the chain of migrations that need to be rebased in a commit, and will rebase them accordingly.

eg: ./manage.py makemigrations --new in your new commit would wipe out the existing list in max_migration.txt and write up the first migration created in the first line. Subsequent migrations don't require you to add this flag, and they are added under each other in the max_migration.txt.

While rebasing, self.last_migration_number would be initialized to the last merged migration, and based on these rebased migrations are renumbered, and eventually self.last_migration_number is updated.

Added necessary tests, and also tested manually in a project requiring rebasing of 3 migrations in an app.

Fixes #27

cc @timabbott

[roanster007]

@adamchainz we are thinking of using this in @zulip. Since we would be quite often making multiple migrations in same app in a commit this feature would be important for us. Let me know what you think about this PR/approach. Thanks!

[roanster007]

@adamchainz Also added a commit, which would fix #184 (unapplies and rebases the migrations rather than throwing out error if migrations that need to be rebased are already applied) Extracted it to a separate PR in #346

[adamchainz]

Thank you for your work here and in the other PR. I haven't found the time to review it fully yet. Here are some initial thoughts.

I think --new is going to be rather error-prone. It requires the developer to remember the flag right at the start of the PR.

Putting multiple migration names in max_migration.txt is also error prone, I think. If branches have common migration names in the middle, Git will not output an easy-to-parse single merge conflict, but multiple. I think we should instead be able to chain of to-rebase migrations from the conflict information itself, by going backwards to the common ancestor of
the two branches.

Anyway, I will try have a play around with the PR soon. I have been doing some other updates here so a bit more familiar with the code right now.