Block API: Introduce abstraction for better management of inspector controls

[artemiomorales]

What problem does this address?

Currently, inspector controls are created inside of a block's Edit component. This means that any modification to those controls must also be done in each block's Edit component on a case-by-case basis, and it is difficult to introduce generic changes that affect a large number of block controls in a robust manner.

But, what if we were to devise a way to introduce a wrapper around each of these inspector controls, allowing us to more easily customize their behavior or appearance?

This impacts at least two potential enhancements:

1. Allow for site builders and admins to granularly control which inspector controls appear or not in the editor based on their use case, which would allow for end users to have a more customized, tailored experience with less cognitive overload
2. With Block Bindings, introduce logic to indicate whether attributes are connected or not in a single location rather than needing to create custom logic inside every Edit component (related issue: https://github.com/WordPress/gutenberg/issues/61406)

What is your proposed solution?

@ellatrix has already done an early exploration here: https://github.com/WordPress/gutenberg/pull/60779

The idea is to move inspector controls to be an attribute of block settings, then render each control separately inside a wrapper, which, as mentioned above, could pave the way for toggling their display on or off, as well as creating robust logic for indicating whether a particular attribute is bound.

[Mamaduka]

Here's also a proposal we drafted a while back - https://github.com/WordPress/gutenberg/discussions/51005.

[talldan]

Also related - https://github.com/WordPress/gutenberg/issues/58233