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
 * 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 a new table to store a mapping of numerical id, content_model, content_format.

Each row in the content_models table will refer to a unique tuple of (content_model, content_format). The page, revision, and archive tables will be modified to only have one *_content_model_id column, which will correspond to a row in content_models. 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 id will only be stored in the database and utilized classes that directly interact with it (Revision, PageArchive, LinkCache) through JOINs or a quick lookup interface. 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.

Including content_format in the 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.