Removed support for initial_data fixtures per deprecation timeline.

docs/topics/testing/overview.txt

@@ -260,9 +260,6 @@ The initial serialization is usually very quick, but if you wish to exclude
 some apps from this process (and speed up test runs slightly), you may add
 those apps to :setting:`TEST_NON_SERIALIZED_APPS`.
 
-Apps without migrations are not affected; ``initial_data`` fixtures are
-reloaded as usual.
-
 Other test conditions
 ---------------------
 
@@ -288,8 +285,6 @@ prepares itself. You can control the level of detail of these messages with the
     Creating test database...
     Creating table myapp_animal
     Creating table myapp_mineral
-    Loading 'initial_data' fixtures...
-    No fixtures found.
 
 This tells you that the test runner is creating a test database, as described
 in the previous section.

docs/topics/testing/tools.txt

@@ -984,18 +984,6 @@ The most straightforward way of creating a fixture is to use the
 already have some data in your database. See the :djadmin:`dumpdata
 documentation<dumpdata>` for more details.
 
-.. note::
-
-    If you've ever run :djadmin:`manage.py migrate<migrate>`, you've
-    already used a fixture without even knowing it! When you call
-    :djadmin:`migrate` in the database for the first time, Django
-    installs a fixture called ``initial_data``. This gives you a way
-    of populating a new database with any initial data, such as a
-    default set of categories.
-
-    Fixtures with other names can always be installed manually using
-    the :djadmin:`manage.py loaddata<loaddata>` command.
-
 .. admonition:: Initial SQL data and testing
 
     Django provides a second way to insert initial data into models --