Add back type defs for no margin bottom prop

[mirka]

What?

Adds back type defs for the __nextHasNoMarginBottom prop (for the components already done in #73848).

Why?

I remembered that we agreed to keep the type def around to prevent consumer builds from failing. Whether or not this prop exists in a consumer codebase is not important, so we shouldn't penalize early adopters by triggering errors.

I will continue this pattern for FocalPointPicker (#73980) and onwards.

Testing Instructions

Passing a __nextHasNoMarginBottom to any of these components should not trigger a TypeScript error. Just a deprecation indicator.

[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: mirka <0mirka00@git.wordpress.org>
Co-authored-by: juanfra <juanfra@git.wordpress.org>
Co-authored-by: aduth <aduth@git.wordpress.org>

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

[github-actions]

Flaky tests detected in 88c0ee6.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20177755196
📝 Reported issues:

• [Flaky Test] should allow user to add and remove multiple local font files #62862 in /test/e2e/specs/site-editor/font-library.spec.js

[juanfra]

Code looks good to me. From what I tested it works well.

[aduth]

Will we have a deprecation lifecycle for removing these passthrough types? 😅 To your point of "Whether or not this prop exists in a consumer codebase is not important", I would agree that it's not especially impactful, but it is technical debt that we carry, and simpler / smaller code is an ideal to strive for.

[mirka]

Will we have a deprecation lifecycle for removing these passthrough types?

The current guidelines are the result of active community feedback, and personally I think it's a fair compromise between maintenance burden and consumer burden, given the historical tendencies of the project. (This balance will definitely shift in the new @wordpress/ui package though!)

A big reason for keeping the type def alive for a while is for consumers having to support multiple WP versions, so maybe it's fine to remove after a few more cycles if these pile up.