Requests for comment/Page protection as a component

Rationale
Make the article protection model easier to maintain and extend.

The system is not written in a modular way, and to decouple from core code we might as well expose the internal API, then move the implementation into an extension. This will have the great benefit of making it trivial to experiment with improvements to page protection, or for administrators to replace its functionality entirely in favor of a model which better suits site requirements.

Wikipedia, for example, would be better served by a gated trunk model similar to the workflows used in DVCS development. In other words, "Kill the 'View Source' button" and always enable editing, even if the user's changes are saved to a sandbox and do not automatically update the public-facing default article contents. It might be possible to do something similar with Extension:FlaggedRevs already.

The core access control system currently in question consist of: a) "protected titles", or a blacklist of titles which are banned and cannot be created; and b) "page restrictions" or "page protection", which prevents editing by role, and can be cascaded to protect all transcluded pages or templates. There is also the role-based access itself, but I saw less benefit in extracting this out.

The work described by this RFC could also be accomplished by componentizing page protection within core, I am interested in whatever gives better results.

Issues
We shouldn't distribute MediaWiki without a permission model, so the new extension would be bundled in core releases and enabled by default.

The refactored code linked below was overly conservative, in order to lubricate review and acceptance. A later phase may include reorganization within the extension, and tweaking of the hooks added to core.

Resources

 * https://gerrit.wikimedia.org/r/23999 - changes to core
 * https://gerrit.wikimedia.org/r/24142 - refactored as an extension
 * https://bugzilla.wikimedia.org/show_bug.cgi?id=40293 - bugtracker for this feature
 * (redlink) Discussion of functional requirements and how strictly we should follow the existing implementation.
 * (redlink) Future directions