It is possible to have overlapping blocks. For instance you can have a block on your user as well as a hard block on an IP address (that also applies to your user). Likewise, you can have an IP Range block that could apply to your IP address and (possibly) your user (if it's a hard block).
`User::getBlockedStatus()`picks a block to use and that is what gets used. This becomes a problem when overlapping blocks have different configuration.
For instance, if a user is partially blocked from Saturn and IP address (hard block) is partially blocked from Mars, The user should be blocked from both Saturn and Mars. Likewise, if either of these blocks are sitewide blocks, the user should be sitewide blocked.
Likewise, if a user is IP blocked and has an overlapping IP Range block, the user should have all of the restrictions of both blocks.
`User::getBlockedStatus()` should user the current block selecting order, if it encounters a sitewide block, it can bail with that block.
If it does **not** find a sitewide block, but it does have one (or more) partial blocks, it should take the first block that is found, and merge any restriction properties (email, user talk, page/namespace restrictions) from the other blocks into it. The block should have a property that, when set, prevents the block from being saved (by throwing an error).
Additionally `Block::chooseBlock()` will need to be deprecated and replaced with this new restriction merging logic.