Consider documenting "expand/contract migrations" pattern

This is a practice that emerged when the NuGet team they was using migrations to evolve the schema of the database back-end for NuGet.org. In @anurse's words:

> Basically, we use code review to make sure that migrations for new features are always purely additive, and go for one iteration with both old and new database schema. Then, once the new code is stable, we deploy code that does not use the old schema and run a migration to remove the old schema. The pattern is sometimes called “Expand/Contract Migrations” because it groups migrations into two categories: Those that are non-destructive expansions of the DB schema and those that are destructive contractions of the schema.

It allowed them keeping their service online most of the time while still leveraging EF migrations.

We decided not try to implement something like this in the product (see https://github.com/aspnet/EntityFrameworkCore/issues/8932) but it is a useful practice customers could learn about in our docs.