Block API: Add action to update existing block registration

[aduth]

Previously: #20544 (comment)

The implementation of #20544 highlights a use-case where it may be necessary to update registered block settings after the initial registration. Today, this can only be achieved by a (non-ideal) mutation of the result of getBlockType.

There is already some precedent in how server-side and client-side registrations are reconciled, where server-side block registrations behave as something of a "base" that the client-side registration updates (source).

Task: Implement means to update existing block registration.

Implementation Ideas:

This may or may not need new APIs. It could be possible to change the behavior of registerBlockType such that "registering" an existing type would simply merge with the current settings.

If a new API is needed, it could be expressed as something like extendBlockType.

Consider also:

• Could this help replace the need for unstable__bootstrapServerSideBlockDefinitions ?
• Will this be a "footgun" if those settings updates aren't reflected based on timings (e.g. attribute types validation only accounted for at initial parse)?
• Should "re-registration" really merge to an existing block type? What about a use-case where I want to wholly replace a block type settings? If we do merge, should it be a shallow merge or a deep merge (e.g. should setting new attributes replace or merge to existing attributes)?