[PP-2] WIP: Experiment to expose config-defined component instance inputs to TMGMT — precursor to Canvas-native translation UX

Good news!

1. I borrowed what you had in here (!833) for config schema over at #3582464: [PP-2] Symmetrically translatable config-defined component trees, STEP 3: adjust sequence keys to avoid translations breaking when component instances are moved's !831. !831 is now green.
2. #3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI in turn is step 2, and thanks to !831, a clear problem emerged that confirms that need: #3582478-2.
3. And just now … I've got an initial MR up that fixes the problem: #3582478-5: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI.

That should allow this MR to become simpler, like we discussed 🤞

!885 looks promising! Can we get some screenshots? 🙏

Those screenshots look amazing! 🤩 Great progress, important validation for #3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI — thanks!

I've incorporated many of the foundational bits in @tedbow's MR here in !898 for #3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI — grep the commits for "tedbow" :)

@tedbow: Based on my research due to the way TMGMT works combined with how Canvas stores its data, you AFAICT could only ever have succeeded in surfacing plain strings, because those end up storing <input name>: <string value (e.g. heading: 'Oh hello there).

So AFAICT this MR could not have made work multi-property field types such as the link field type which is used to populate type: string, format: uri. Is that right?

If we end up making this work, it would have to land after #3582478: Symmetrically translatable config-defined component trees, STEP 2: change config schema type for `inputs` to allow translating via core's Config Translation UI. Reflecting that in the issue title.

I ran into the wordCount thing too, it's in the stack trace in the MR comment I linked from #9. The only way to avoid it is to build a custom ConfigProcessorInterface (which you started doing in !833).
It'd have to extract just the string field properties of multi-property field types (so for the text field type, extract only value as a translatable) and pass along other field properties as context (so format: canvas_html_block) — or something along those lines.

Adjusting issue title to reflect why this is so important.

In a meeting with @lauriii yesterday, he emphasized the intent to make translations focus just on strings, because that would allow:

• automated translation (whether to a translation provider powered by humans, a machine, an LLM …)\
• the future integrated-into-Canvas'-UI translation UX to likely be simpler, too

Related: @tedbow opened #3585452: Create a preview mode for non-default languages in which he shows what the initial goal is: translate outside Canvas' UI, (pre)view translations inside Canvas' UI.

Due to core's Content Translation UX relying on field widgets, and Canvas' "component tree" field type not having a widget, #3583684: [PP-1] Symmetric translations for content entities should allow only translatable properties in inputs to be overridden is kinda forced to use TMGMT to translate content-defined component trees.

IOW: ~50% of this issue is being implemented there. Postponing this on that one.