Refactor watchlist token handling

Refactor watchlist token handling

Do not allow the user to change it directly; instead create a form
where they can reset it. (The token can still be changed via the API.)
The token is autogenerated whenever it is shown or otherwise used.

This really should have never used the preferences; however, trying to
change that now would be lots of work for very little gain, so this
keeps using that mechanism, adding a little abstraction over it.

It's not unconceivable that similar tokens could be used for other
pieces of data, like Echo's notifications; this enables that with one
new hook.

----

Things done here:

* Add getTokenFromOption() and resetTokenFromOption() methods to User,
  abstracting out the get-and-generate-if-empty process of handling
  tokens. Respect $wgHiddenPrefs (Watchlist didn't do that
  previously).

* Create Special:ResetTokens, inspired by Special:Preferences and
  Special:ChangeEmail, presenting the token resetting interface
  (HTMLForm-based with CSRF protection).

* Create a new hook, SpecialResetTokensTokens, allowing extensions to
  register tokens to be shown in the resetting form. Each token needs
  information about the preference it corresponds to and a short
  description (used for checkbox label).

* Hide the preference on Special:Preferences (use type=api to achieve
  this), display a link to aforementioned special page instead. Move
  info blurb to its own section at the bottom.

Bug: 21912
Change-Id: I0bdd2469972c4af81bfb480e9dde58cdd14c67a8