[FEATURE]: Simple inference format to emit a single Component or non-nested vertical list of Components

## Background

Many integrations of A2UI are chat apps. In some cases, we see that developers just want the agent to instantiate one or two Components inline, with no nesting. This often occurs because they are using complex, domain-specific components that they have built themselves, and will occur even more in the future with https://github.com/a2ui-project/a2ui/issues/775 (now called "Macros" - see https://github.com/a2ui-project/a2ui/pull/2519 and https://github.com/a2ui-project/a2ui/pull/2520) and a future "Templates" feature. If the agent developer can define a set of macros or templates ahead of time for common UI needs, then then the agent can just instantiate them. This is very similar to OpenAI's ChatKit architecture, except that A2UI provides more flexibility in some ways (ability to define your own underlying catalog, mobile support, ability to upgrade from simple template instantiation to full Gen UI etc).

In these cases, even the express format is overly complex, because it has concepts of nesting, variable assignment etc which the LLM does not need to understand if it is just wanting to instantiate some components. So, there is an opportunity for us to define a new inference format that is highly restrictive but theoretically can support even smaller models and have lower latency and higher reliability.

## New "Vertical" format requirements

- LLM can instantiate one or more Components. Each component is displayed in a vertical list. One option is that if there are multiple components, the compiler can automatically nest them inside a List component, though that requires List to be in the Catalog. Alternatively, we can just design the format to represent *exactly* one component, and then the agent can create additional blocks to instantiate more components. That probably is simpler.
- Catalog Components that require children should be ignored, because children cannot be specified
- Format should be very simple
- The LLM never specifies surface ID - that is created automatically, or possibly each block is a separate a2ui context so we can use a default surface ID - the same for every surface (see https://github.com/a2ui-project/a2ui/issues/2173)
- The syntax should be as simple as possible and token efficient. Consider how the express format can help with that.
- The prompt should be generated from a specific catalog, the same as we do for other inference formats, like express.
- There parser should be very permissive and really try to fix invalid syntaxes. The simple syntax should make that easy.
- We should hooks this up to the eval suite, and create a table comparing performance with express, on Gemini Flash and Flash Lite specifically. Include thinking token usage in the table.

Tips
- Look at other inference formats to understand how they are set up
- Use clear input/output data driven tests for the compiler etc