Related: #24874

Description

Background

As part of looking to add custom margins (gutters) to the column/s blocks, we run into an issue with the spacing block support styles being added as inline styles. This won't play nice with the CSS media queries that stack the columns at different viewports. These queries look to set a flex-basis for the column width taking into account margins so they stack correctly.

This highlighted the fact that the option to skip serialization of the padding and margin block support styles wasn't available. This PR allows for that skipping of serialization.

How has this been tested?

Manually.

Test Notes

• The test instructions are just for testing that the serialization is skipped. This PR doesn't update any blocks.
• If testing with group block, block patterns with existing padding will throw block errors.

Test Instructions

1. Turn on customMargin under the spacing support in your theme.json
2. Update the Group block's block.json to enable both padding and margin support while skipping serialization - gist
3. Create a new post and add a group block to it. (setting background color can help testing)
4. Adjust the block's padding and margin values in the sidebar
   The block's spacing shouldn't change although color selections etc should be applied and the block visually update
5. Switch to the code editor view
6. Confirm the padding and margin attributes reflect the values set
7. Confirm that the block's markup does not contain inline styles for either padding or margins
8. Save the post and view on the frontend. Confirm there are no padding or margin styles
9. Update the Site Title block's block.json file to skip serialization (or any other dynamic block with spacing support) - gist
10. Add Site Title block to the post and set padding and margin
11. Save the post and confirm that there are no padding and margin inline styles on the site title on the frontend

Screenshots

Types of changes

New feature

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).