Incorrect behaviour for block page visibility

This is not merely unintuitive/confusing, if this problem occurs, the UX is telling people they do not even need to look at this (as noted by geekygnr in #24 🐛 Incorrect behaviour for block page visibility Needs work and alison in #26 🐛 Incorrect behaviour for block page visibility Needs work ).

1. Leave "Pages" blank.
2. Have the "Show for the listed pages" and "Hide for the listed pages" radio buttons set to "Hide for the listed pages"
3. The summary of Visibility will tell you Pages are "Not restricted" when in fact it is restricted so severely it will not show on any page.

Given that fixing this ought to change the behavior in the edge cases of blank lists, we should make that change, and so will also need an update hook to do so.

Even if we do not change stored configuration we should have an update that provides a link to the change record informing people the user interface behavior has changed (whether anything is updated or not). The update hook should further specifically alert people that the configuration they have may be leading to an unexpected result of hiding their block from every page, if they have 'negate' ('hide_on_pages' => 'Hide on specific pages') checked and the Pages textarea blank.

If we don't want to allow such a confusing case (the default of displaying everywhere is fixed by the 'Show on all pages' radio button in the patch) then we need a fourth radio button 'Hide on all pages' or we need to update such blocks to be disabled. (The latter is better in my opinion, provided we let people know which blocks were in such a state. But i'm not sure how that would interact with other visibility display settings, let alone more complex modules like Block Visibility Groups.)

Where does the logic to invert the standard behavior for a blank list actually happen? I know it's sort of common in Drupal but whenever it is also paired with 'Negate the condition' the double negative (negate an empty list that is interpreted as everywhere == hide everywhere) is bound to be counterintuitive anywhere it comes up. I cannot find it in core/modules/system/src/Plugin/Condition/RequestPath.php or core/lib/Drupal/Core/Condition/ConditionPluginBase.php (which provides negate as a default option) nor in core/lib/Drupal/Core/Path/PathMatcher.php.

Block visibility based on Vocabulary (using core/lib/Drupal/Core/Entity/Plugin/Condition/EntityBundle.php i think) has the same odd behavior (you can select nothing at all, choose negate the condition, and then the block is hidden everywhere) but at least it doesn't set any expectations at all— no help text at all and no summary in the vertical tabs!

Some or all of my comments are probably for follow-up issues. A lot of work has been put into this, especially by paulocs; it would be wonderful to get this across the finish line.

MR has conflicts even with 9.x (but also needs to be redone against 11.x) -- anyway, adding "needs reroll" tag (right?)

I don't think I did it particularly well but I have started a re-roll to 11.x

Testing the UI I think it is working as expected but there is probably still a lot of fixing to do.

I cherry picked the commit but the merge conflicts were difficult to resolve. It will need additional work.

I rolled out the 11.x fix and got all the tests to pass.