(bug 46905) Add "centralauthtoken" to API

Since third-party cookies (and therefore SUL) don't work with a growing
number of browsers, we need a non-cookie-based way for CentralAuth to
pass authentication data for CORS requests.

This adds a "centralauthtoken" parameter to the API "main" module, and a
new token type to action=tokens. The client requests a token from the
local wiki and then immediately uses it in the CORS request. The remote
wiki will then ignore all cookies and instead take the user data and
session ids from memcached using that token.

Bug: 46905
Add Javascript login check against the central wiki

The ability for CentralAuth to log the user in everywhere via a "push"
model is going away, as browsers tighten their security on third-party
cookies.

This changes things to a "pull" model instead. If the user is logged
out, a request is sent to the central wiki, which puts the necessary
data in memcache so we can set the necessary cookies as first-party
instead. To avoid doing this with every page view, it is instead done
just once and a cookie or localStorage token is set to remember this.

Note that, to allow Internet Explorer to be able to send and receive the
cookies via CORS or the iframe, a P3P header must be included when the
cookies are set on the central domain and when the iframe content is
served from the central domain. The default policy used is clearly
invalid: it has no valid tokens at all, while a real policy must contain
at least an "access" token and one statement, which would contain either
the NID token or at least one "purpose" token, one "recipient" token,
and one "retention" token.
Added $wgCentralAuthLoginWiki option.

* This changes login to redirect to a central login wiki and back to set
  the cross-domain cookie for that wiki. This works around browsers not
  letting third party domain cookies get set directly.

Requires change Idd71cac47195402ebffeb7047e91efb200a32b58 to core.

Bug: 46903

Conflicts:
	CentralAuth.php
	CentralAuthHooks.php