Structure the schema and rendering code by widget

[jacobsimionato]

Description

Update the structure of the code to centralize the definition of each Gen UI widget (know as a CatalogItem in the code), so that we can easily add new CatalogItems.

Overview of new structure

• CatalogItem: represent a single widget that the LLM can create and manipulate
• Catalog: represents a specific set of CatalogItems which can be exposed to the LLM
• DynamicUi:
• WidgetTreeLlmAdaptor: represents a way that the LLM can output and manipulate widget trees for a specific Catalog. E.g. the current protocol which supports CRUD operations. This could be swapped out for other protocol styles. This currently just includes the schema part of this, but it'd be nice to later combine this with the code that handles the outputs that match this schema.

CatalogItem API

This is intended to just include all the necessary logic to define and render a single widget.

• Widgets which need to maintain ephemeral UI state e.g. RadioGroups etc are implemented as StatefulWidgets. This keeps all the state management inside the widget definition.

Existing Catalog

I haven't migrated every catalog item, because I want to get feedback on the API before doing so. It's easy to migrate the rest using Gemini CLI!

Future ideas

• Factor out the concept of child widgets referred to via IDs into some abstract concept that is administered at the WidgetTreeLlmAdaptor layer. E.g. in the schema for each CatalogItem, it could just insert a "childReference()" using a callback that is passed in. Then when deserializing, the childBuilder() could just accept a dynamic object which can then be handled in different ways by different WidgetTreeLlmAdaptor implementations. E.g. currently we use adjacency lists, but this would let us migrate to a fully inlined hierarchical JSON format using $ref and $def, without having to rewrite all of the CatalogItems.