Ensure block hooks keep user state consistent with realistic blocks

Ensure block hooks keep user state consistent with realistic blocks

Several block-related hooks allow the user to be put into in a state
that is inconsistent with blocks that can actually be made:
* With UserIsHidden, User::mHideName can be set to true without there
  being a block
* With UserIsBlockedFrom, a user can be blocked from editing a page
  without there being a block
* With GetBlockedStatus, public block properties can be arbitrarily
  set on a user

These problems are mostly theoretical, but mean that it is impossible to
make some basic assumptions, e.g. that a user who is blocked from a page
must have a block. The hooks are not widely used, and with a few changes
we can make them more robust so such assumptions can be made.

This patch:
* Ensures UserIsBlockedFrom is only called if there is a block. This
  would be a breaking change if any extensions were using this to block
  an unblocked user; the intended use case is clearly for extensions to
  allow user talk page access to blocked users.
* Adds a new hook, GetUserBlockComplete, which passes the block for
  modification. This should be used instead GetBlockedStatus and
  UserIsHidden, which will be deprecated in the future.
* Allows the 'hideName' option to be passed into the AbstractBlock
  constructor so that suppressing system blocks can be made.

Bug: T228948
Bug: T229035
Change-Id: I6f145335abeb16775b08e8c7c751a01f113281e3