[PP-1] Implement client-side validation of block settings

This to me is definite polish, a nice-to-have, not a must-have for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active .

Why?

Because:

• 99% of BlockPluginInterface implementations' forms do not have any validation at all — client nor server-side. The range of possible settings values allowed through the UI is constrained only by the HTML input element they picked (<select>, <input type="checkbox">, etc.)
• It's only since a few months (since 📌 Make Block config entities fully validatable Fixed ) that a few block plugins are fully validatable …
• … and it's only those few block plugins that have a precise config schema that would even allow for this! 😰
• I'm convinced that >50% of placed blocks contain invalid/nonsensical block settings, that only sort of work due to PHP's automatic typecasting — having worked on https://www.drupal.org/project/acquia_migrate → , and having seen the incredibly weird/convoluted/puzzling "settings" many placed blocks were accepting without complaining.
• Actually, even outside a migration context, the only reason block plugins' settings forms work at all is precisely because both the PHP typecasting magic in the form definition is matched with the Form API submission typecasting magic, and is matched with the block plugin's ::build() method's interpreting of the saved values

📌 Implement saving block settings forms Active is in, but I imagine we'll at least want to do 📌 [PP-2] Remove InputBehaviorsBlockSettingsForm and consolidate with input components form Active first?

📌 [PP-2] Remove InputBehaviorsBlockSettingsForm and consolidate with input components form Active is in, too.

📌 Decouple generated source plugins from SDC plugins Active blocks this in my book

Per #3513589-6: [PP-1] Decouple generated source plugins from SDC plugins → , that is PP-1.