Provide context when blocks.registerBlockType is applied to deprecations

[ethitter]

Description

The blocks.registerBlockType filter is applied both to the block's full settings as well as to the settings for its deprecations. If care is not taken, a change intended for the current block's settings can be applied to one of its deprecations unintentionally, with the potential to break the deprecation. This can be avoided by testing the block's settings before applying changes via the filter, but the block's settings may not always be changed in a way that can easily be discerned. To assist with determining the context in which the filter is applied, the deprecation's settings are passed as a third argument, and null is passed when the filter is applied to the block's complete settings.

How has this been tested?

Added a filter that expects three arguments, confirmed that received arguments were as expected.

Screenshots

Types of changes

• Adds third argument to blocks.registerBlockType that is null when filtering the full settings, and contains a deprecation's settings when applied to one of the block's deprecations.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• 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 (please manually search all *.native.js files for terms that need renaming or removal).

[gziolo]

@youknowriad and @mcsf, what are your thoughts on the proposed approach? I can see how filters mixed with deprecations might cause issues. In particular when a filter gets introduced long after the depreciation was created.

[youknowriad]

I think it's fine yes.

[gziolo]

Let's get this enhancement included. Thank you for the nice idea 👍🏻

[mcsf]

Nice! I missed the ping back in November. Great seeing you here, @ethitter, saudades! 😄