Requests for comment/Content model storage

A proposal to change how we store content model and format in the page, revision, and archive tables. This has mainly come up as we are changing namespaces from a default content model of "wikitext" to "flow-board".

Background
Current abbreviated schema:

Problems
The current system for storing a page's (and revision's) content model in the database is non-optimal.
 * The content model and format of a revision is stored as NULL if it is the default. This makes changing the default problematic, as it requires updating all rows in the revision and archive table where the default is changing
 * Moving a page from "MediaWiki:FooBar.js" -> "MediaWiki:FooBar.css" changes the default content model, so it has to update all revision history rows to set an explicit rev_content_model (226938)
 * content model and content format are stored as strings ("wikitext" and "text/x-wiki" respectively) which is inefficient from a storage point of view
 * This makes adding an index to page_content_model for features like Create an automated listing of all Flow Boards on a wiki (aka Special:PagesWithContentModel) very expensive

Proposal
Create two new tables, one assign content models an id, and another to assign content formats an id.

The page, revision, and archive tables will be modified to only have *_content_model_id column, and *_content_format_id columns. This field will always be populated, even if it is the default value (with the exception of the time period when the schema change is taking place and the column hasn't been populated yet).

The numerical ids will only be stored in the database and utilized classes that directly interact with it (Revision, PageArchive, LinkCache) through a quick lookup interface that is cached in APC or something similar. It is expected that PHP code will continue to use the PHP API (Title::getContentModel, Revision::getContentModel, etc.) which will use the text form of the model and format. api.php output and dumps would continue to output the text forms as well.

Creating a separate content_format table will prevent us from needing to do a similar change in the future whenever we'd like to change that default, though there is no current need to set a non-default format AFAIK.

Migration

 * Add new page_content_model_id, page_content_format_id, rev_content_model_id, rev_content_format_id, ar_content_model_id, ar_content_format_id columns.
 * Update MediaWiki to read those columns and fallback on the old *_content_model,*_content_format ones if it isn't populated yet
 * Run maintenance script to populate the new columns
 * Drop old *_content_model, *_content_format colums

This will be done automatically by update.php.