Stable interface policy

I propose to replace the Scope section of the deprecation policy with the version below, which is more explicit about defining the stable interface governed by the deprecation policy:

Scope
This proposed policy applies to the PHP code of the MediaWiki core (mediawiki/core.git) codebase. It explicitly does not apply to the api.php API, client-side JavaScript, HTML output, or database schemas. Those should (and do) have their own deprecation practices. If changes do affect those components, they should also follow those deprecation practices as necessary. As with all policies, developers should apply their best judgement when following it, and use common sense as necessary.

More specifically, this policy applies to the stable interface presented by the PHP code, as defined in the following section.

Stable Interfaces
The following things are considered part of the stable interface, and therefore subject to this deprecation policy, after having been present in at least one stable release:
 * global functions with the "wf" prefix, unless marked with the @internal annotation or otherwise documented to be unstable, experimental, or deprecated.
 * all public methods and fields of classes, unless the class or the method is marked with the @internal annotation or otherwise documented to be unstable, experimental, or deprecated. This does not include methods and fields that are lacking any access modifiers. The the note on legacy code below.
 * all documented hooks, unless the hook is documented to be internal, unstable, experimental or deprecated.
 * only some protected methods and fields of classes, namely ones that belong to classes that are documented to act as extension points or explicitly allow subclassing outside the MediaWiki core module.
 * only some constructor signatures, namely ones that belong to classes that are documented to act as extension points or explicitly allow subclassing outside the MediaWiki core module, as well as the constructor signatures of classes documented to defined pure value objects.
 * only some interface signatures, namely ones of interfaces that are documented to act as extension points or explicitly allow implementation by code outside the MediaWiki core module.

In contrast, the following thigs are not part of the stable interface, and are therefore subject to change without notice:
 * protected methods and fields of classes, except ones that belong to classes that are documented to act as extension points or explicitly allow subclassing outside the MediaWiki core module.
 * constructor signatures, except ones that belong to classes that are documented to act as extension points or explicitly allow subclassing outside the MediaWiki core module, as well as the constructor signatures of classes documented to defined pure value objects.
 * interface signatures, except ones of interfaces that are documented to act as extension points or explicitly allow implementation by code outside the MediaWiki core module.
 * global variables, including those with the "wg" prefix. MediaWikiServices should be used as an entry point that provides access to service objects and configuration instead.

In summary, code outside of MediaWiki core, particularly in MediaWiki extensions, should expect that:
 * it's generally safe to call public methods and access public fields in classes defined by MediaWiki core.
 * it's generally unsafe to extend (subclass) a class or implement an interface defined by MediaWiki core, unless that class or interface was designated to be safe for that purpose.
 * it's generally unsafe to directly instantiate (using new) a class defined by MediaWiki core, unless that class is designated to be safe for this purpose (in particular, when the class represents a pure value object).

Some legacy code may not have any access modifiers, in which case it is not considered to be part of the stable, public interface. Developers SHOULD add visibility modifiers as soon as possible, and use judgement when making this code protected or private. Where known users exist, developers should still consider following the full deprecation process. New code MUST have explicit visiblity set on all properties and functions.