Blocks: Add the missing alignments classNames to the Cover Image Block's markup

[youknowriad]

closes #2650

Tiny PR adding the missing alignment classNames to the cover image block. It also declares a "deprecated" version to avoid invalidating old cover image blocks.

Testing instructions

• Declare wide alignment support for your theme:

add_theme_support( 'gutenberg', array(
        'wide-images' => true,
) );

• Add a cover image
• Click "full alignment" button
• Switch to the Code editor, you should see a "alignfull" className on the cover-image's figure wrapper.

[aduth]

Seems an extreme change to fix a minor bug 😕 But unless we want to relent that a class name change is not an invalidating change (it could have breaking impact) or that fixing bugs might invalidate old blocks, seems necessary.

[aduth]

Do you think it'd be reasonable for omitting the attributes property from a deprecated definition to default to the current attribute set, since we're not changing anything about it? I guess this could be a concern for future maintainability if we did decide to later change it.

[youknowriad]

The problem we this, is that an undefined value means no attributes right now. I guess we can still use {} as a replacement. The same could be said for supports. I don't feel strongly either way. Both have drawbacks:

• The necessity to repeat the value if no changes
• The necessity to understand that {} is different than omitting the property for the second option.

[youknowriad]

@aduth I think the default value is "center". What if we avoid adding the className if the alignment is "center" and avoid the "deprecated" declaration entirely?

[aduth]

Is the default center? For images it would be alignnone. Not sure if we made a point to be consistent with those defaults across block types (could be relevant for #4069).

[youknowriad]

mmmm, It's not. I guess I assumed it was "center" because I had a "centered" cover image when testing.

So this makes things easier IMO. We can just drop the "deprecated" declaration as is. This could produce "invalid" blocks but the chance for it to happen is small.

[gziolo]

Yes, I also share the same view. That it is a lot of code to add and process to fix a very small bug for a relatively simple block. We should watch closely how deprecation feature is used for blocks and take an action if this becomes too complicated to manage. On the other hand, maybe we should always copy and paste the version that gets updated but put everything in their own file to make sure it doesn't pollute the existing solution.

The fix itself looks good :)

[youknowriad]

Ok, since the default use-case is not affected, I've removed the deprecated block's definition. What do you think about moving forward as is?

[gziolo]

Let's apply this as it is :)