Allow defining the default style at runtime

[oandregal]

As part of improving the block style variations #7551 we need the ability to set the default style at runtime.

This PR adds the setDefaultBlockStyle low-level primitive.

Testing

Execute npm run test-unit.

1. Compile this branch: npm install && npm run dev.
2. Open the block editor and add a quote block.
3. Open the InspectorControl and note that the default style is "default".
4. Open the developer console and execute: wp.data.dispatch( 'core/block' ).setDefaultBlockStyle( 'core/quote', 'large' ).
5. Add a new quote block.
6. Open the InspectorControl and note that the default style is the large one.

So far, the new block doesn't reflect the large style. The reason is that the CSS classes for default block styles don't get applied to the block until the user specifically clicks the style. Because the style class is-style-large is not applied, the CSS for the block is still the initial default style, not the one defined at runtime.

[oandregal]

When a block is first added it doesn't get the style class is-style-X applied. The user has to click one of the block styles for the corresponding class to be added. At the CSS level, we cover for this lack of default class by providing the default styles to the block itself.

Take the quote block as an example. Essentially, what we do is:

.wp-block-quote {

    // rules for the default style, to cover the fact that the block
    // doesn't get the `is-style-default` class applied

    &.is-style-large {
        // rules for the large style
    }
}

What if we always added one style class to the block, even for the default style?

With this approach, the className attribute for the block would get:

1. the block class name. Ex: wp-block-quote.
2. the style that is applied (or the default if none). Ex: is-style-large.
3. the user-defined classes in the Advanced class text field control.

Currently, block styles are exposed in the Advanced CSS class text field in the block sidebar. The user can edit and remove those classes. If we want to make sure one of them is always applied, it makes sense not to expose them in the Advanced CSS class component.

Does this approach looks like something we want? Are there any other issues to be considered?

[oandregal]

From this slack convo in core-editor: currently, this state lives in core/blocks and is created from the static definition of the block. If we allow for it to change, we need a way to persist it across sessions. Open questions: could this live in the localStorage as a first step? is this more user state than it is application state?

[oandregal]

Cleaning up my lingering PRs. We can reopen if necessary.