Cover block: improve overlay opacity handling

[stokesman]

Fixes: #25290 which I believe was created by the change from #20904 as it moved the assignment of the black background color into a selector with greater specificity. That PR and its comments are also relevant here because in them an alternative fix was suggested by @jasmussen which is part of the changes in this PR. That is removing the styled fallback background color from the cover. (I'm not referring to it as the default background color because it's just styled and not part of the block attributes). The idea was discarded since it would "break" the dimming feature but if there's no background color or gradient set, that feature just shouldn't be available. Which is what has been done in this PR.

Besides that this gives the opacity range slider a step in accord with the available opacity styles 68419b4 and includes a very minor CSS optimization 0fb0fed.

Note: I'd say part of the issue in #25290 is that the has-background-dim class is inappropriately applied to the block. I initially started on a fix by improving the logic for when that class is applied. However, that leads to block validation failures. If there's a way to handle the migration/upgrade of a block then that'd still be a nice thing to fix.

Screen recording demonstrating availability of opacity control only with application of background color (also stepped opacity increments)

Also worth noting that the background image used in that recording would not even be visible without the changes in this PR.

How has this been tested?

WordPress 5.5.1, creating various Cover blocks with and without images and background colors.

Types of changes

Bugfix

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[jasmussen]

Very nice. This is my before:

And this is after:

And so as you can see, purely based on those GIFs, this PR solves that issue.

I also verified that this fixes the issue for the overlay aspect as well. Editor:

Frontend:

Currently all overlays are black 🙈 so this would be a nice PR to land!

[mkaz]

This looks good, tested well. No problems 👍

[sirreal]

This may have introduced a regression, I've just filed an issue: #26545

[sirreal]

Should this have become $black because the inherited background-color was removed?

[stokesman]

If that were to be $black themes would have to write some quite different styles to have their colors apply on Covers. The removal was motivated by pretty much that issue #25290, the way it made theme background style selectors need extra specificity. As an example, from twentytwenty:
:root .has-primary-background-color { ... }
Whereas the docs on defining those use a simple class selector.
Also, the inherit here is for when there's a defined background color via the block attributes.

[jasmussen]

I have a "fix" in #26564, that I'd love your thoughts on.