Block Editor: Validate options for the 'HeadingLevelDropdown' component

[philwp]

Resolves #65422

What?

This PR prevents values that would end up as invalid heading levels from appearing in the HeaderLevelDropdown

Why?

We do not want to allow options that will result in heading tags that do not exist.

How?

The values passed to options are filtered to only allow values that are included in HEADING_LEVELS. This PR still allows 0 as an option as well, in order to handle the case where passing 0 will result in a p tag.

Testing Instructions

1. Open a post or page.
2. Insert a heading block via the code editor.

 <!-- wp:heading {"level":4,"levelOptions":[4,5,6,7,"foo"],"className":"wp-block-heading"} -->
<h4 class="wp-block-heading">Markup example</h4>
<!-- /wp:heading -->

3. Switch to the Visual editor only h4, h5, h6 are available as choices

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: philwp <philwebs@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[philwp]

I wonder if we should also add an additional attribute for setting 0 as an allowed value to HeadingLevelDropDown? It should probably default to false, that way it is only necessary to add it to the blocks that can currently handle 0 properly. If we leave my fix the way it is currently implemented, we are avoiding most cases with the incorrect markup, but not all.

[ndiego]

@Mamaduka @t-hamano @noisysocks, whenever you have a chance, can you review this implementation? This fix is needed, but I defer to you all the best way to accomplish it. 🙏

[Mamaduka]

Thank you, @philwp! The fix makes sense and works as expected ✅

Ideally, similar validation should happen at the attribute level, and unsupported values should be discarded, maybe logging a warning in the console.

Example: Updated attribute definition for Heading block:

"levelOptions": {
	"type": "array",
	"items": {
		"enum": [ 1, 2, 3, 4, 5, 6 ],
		"type": "number"
	}
}

[Mamaduka]

Note: While usually sorting callback can be omitted in similar cases, this is safer when dealing with numeric values.

[github-actions]

I just cherry-picked this PR to the wp/6.7 branch to get it included in the next release: d6dfb79