[SPIKE] Prove that it's possible to apply block settings update paths to stored XB component trees

Overview

📌 Define `props` in the context of Block components Active is fixed, which means block settings can now be stored (and since 📌 Move SDC specific validation in ValidComponentTreeConstraintValidator::validate into the SDC source plugin Active are guaranteed to be valid).

Maintainers of block plugins can make changes to their config schema (to add/change/remove settings).

How does XB allow those maintainers to provide an update path that also updates all XB-stored component trees?

See search_post_update_block_with_empty_page_id(), tested by SearchBlockPageIdUpdatePathTest and added in 📌 Make Block config entities fully validatable Fixed for an example — which ensures the search block's page_id setting is valid.

Proposed resolution

• We need to write an update path + update path test that does the exact same thing for a search block stored in an XB component tree.
• Start with an XB component tree in an XB field on a content entity.
• Then ensure it also updates an XB component tree in e.g. the PageTemplate config entity.

  This likely can take inspiration from 📌 Prevent modules from being uninstalled if they provide field types used in an Experience Builder field Fixed .

  User interface changes

  None.