SQLite foreign key constraints are not repointed on model or field rename

[Simon Charette]

SQLite foreign key constraints are not automatically repointed on table or column renames which is going to cause a issues to projects who previously renamed a model or a column referenced by another model when they migrate to Django 2.0 which start enforcing them.

e.g. of a SQLite3 session

SQLite version 3.11.0 2016-02-15 17:29:24
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TABLE foo ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT);
sqlite> CREATE TABLE bar ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "foo_id" integer NOT NULL REFERENCES "foo" ("id") DEFERRABLE INITIALLY DEFERRED);
sqlite> ALTER TABLE foo RENAME TO renamed;
sqlite> .schema bar
CREATE TABLE bar ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "foo_id" integer NOT NULL REFERENCES "foo" ("id") DEFERRABLE INITIALLY DEFERRED);  # It still points to "foo"
sqlite> INSERT INTO bar (foo_id) VALUES (999);
sqlite> PRAGMA foreign_keys = ON; # From Django 2.0+
sqlite> INSERT INTO bar (foo_id) VALUES (999);
Error: no such table: main.foo

Since we're already documenting that ​users should remake their tables it should alleviate the issue but we should also sure to:

1. Document that tables that have been previously renamed (or had a column referenced by a ForeignKey(to_field) renamed) must be rebuilt.
2. Adjust SQLite's schema editor to remake tables referencing a renamed table or one that is remade to simulate a column rename to prevent this from happening from now on.

This was discovered while working on fixing #25817.