Removed docs about unmigrated apps as they are not supported in Django 1.9.

docs/ref/django-admin.txt

@@ -696,8 +696,7 @@ Migrations, their relationship with apps and more are covered in depth in
 
 The behavior of this command changes depending on the arguments provided:
 
-* No arguments: All migrated apps have all of their migrations run,
-  and all unmigrated apps are synchronized with the database,
+* No arguments: All apps have all of their migrations run.
 * ``<app_label>``: The specified app has its migrations run, up to the most
   recent migration. This may involve running other apps' migrations too, due
   to dependencies.

docs/spelling_wordlist

@@ -690,7 +690,6 @@ uniterated
 unittest
 unittests
 unlocalize
-unmigrated
 unparseable
 unpickle
 unpickled

docs/topics/migrations.txt

@@ -24,11 +24,6 @@ and Django's handling of database schema:
 
 * :djadmin:`sqlmigrate`, which displays the SQL statements for a migration.
 
-It's worth noting that migrations are created and run on a per-app basis.
-In particular, it's possible to have apps that *do not use migrations* (these
-are referred to as "unmigrated" apps) - these apps will instead mimic the
-legacy behavior of just adding new models.
-
 You should think of migrations as a version control system for your database
 schema. ``makemigrations`` is responsible for packaging up your model changes
 into individual migration files - analogous to commits - and ``migrate`` is
@@ -139,9 +134,6 @@ database to make sure they work as expected::
       Rendering model states... DONE
       Applying books.0003_auto... OK
 
-The command runs in two stages; first, it synchronizes unmigrated apps, and
-then it runs any migrations that have not yet been applied.
-
 Once the migration is applied, commit the migration and the models change
 to your version control system as a single commit - that way, when other
 developers (or your production servers) check out the code, they'll