Requests for comment/image and oldimage tables

There's no auto-incrementing primary key for, and no primary key at all for. This should be changed so that we can uniquely and  performantly identify files and their revisions.

Use cases

 * API Improvements
 * prop=imageinfo - Use revision ID instead of fragile timestamp as identifier.
 * Technical debt
 * LocalFile::recordUpload2 - Eliminate timestamp kludge.
 * End-user improvements
 * Language-neutral file identifiers (see User:NeilK/Multimedia2011/Titles).
 * Remove need for globally unique "file titles" during uploads.
 * T139294: Persistent media links for file versions
 * T33257: File properties storage
 * License integration MediaWiki

1. Add primary keys
This solution is easier to implement and execute since it's a less drastic change.
 * Summary

The down side is that it keeps all technical debt, performance problems, and legacy infrastructure. There will still be no separation between entity and its versions, and there will still be needless separation between the current and older versions of a file.

Effective change Migration strategy Behaviour
 * Add  , , and   fields to the image and oldimage table respectively. (See Database layout.)
 * img_id: Primary key
 * oi_id: Primary key
 * oi_img_id: The value of img_id before the version was moved from image to oldimage
 * Create new fields and populate them with a script.
 * As before, creating a file revision requires atomic moving of the image metadata to the oldimage table, before the new current data can be overwritten.
 * When creating a file revision, set  to the file's former.

2. Separate entity and versioning
Eliminates the legacy handling of needing to interact with two tables for most operations (image and oldimage).
 * Advantages

Brings the file tables in line with the and  table. This will create proper semantic separation between file entities and the versions of their (mutable) content.

Effective change Migration strategy Behaviour
 * Add,  ,  , and   fields.
 * img_id: Primary key
 * img_latest: oi_id of the current version of an image (similar to )
 * oi_id: Primary key
 * oi_img: img_id of the image this version corresponds to (similar to )
 * (Optional) Rename oldimage to "imagerevision". Or, rename image to "file" and oldimage to "filerevision".
 * Create new fields and populate them with a script.
 * (Requires freeze?) Backfill file_revision with the "current" image data.
 * Metadata no longer lives spread over two tables.
 * Creating a file revision involves inserting a new file_revision row and updating the file.img_latest pointer.

3. Replace with MCR
Multi-content revisions as per T107595.

We could eventually stop using the current image/file tables, in favour of storing the information in the main page/revision tables. We'd obviously not store the file binary in the text table. But we could make file-backend references from there, similar to what we do with ExternalStorage already.

We could still keep a simplified image (or "file") table as secondary data (similar to "categories") - which would give us file IDs separate from page IDs, which may be useful. (Where file names rarely clash unintentionally, page IDs would obviously conflict all the time with the remote wiki.)