Add documentation for the a2ui protocol message lifecycle

[jacobsimionato]

As requested by some customers, this adds some docs on the A2UI protocol. This will be unnecessary once A2UI has better public documentation, but this is to help in the mean time.

[gemini-code-assist]

Code Review

This pull request adds valuable documentation for the A2UI protocol message lifecycle, which will be helpful for customers and developers. The new guide is well-structured and clearly explains the core concepts. I've provided a couple of suggestions to enhance the completeness and accuracy of the documentation, mainly by including the deleteSurface message and clarifying the behavior of surfaceUpdate. I also suggested adding a newline at the end of the file, which is a common best practice.

[gemini-code-assist]

The documentation is clear and well-written. I have a couple of suggestions to improve its accuracy and completeness:

1. The introduction and "Key Messages" section omit the deleteSurface message, which is part of the A2UI protocol and handled in the codebase. It would be beneficial to include it for completeness.
2. The description for surfaceUpdate states that "The client buffers these component definitions upon receipt." This is only true for "Strategy 1". For "Strategy 2", components are rendered immediately. The description should be more general to cover both cases.

[A2UI](https://a2ui.org/) is a new protocol for servers to describe a user interface to a client by sending a stream of JSON messages. This document outlines the roles of the four core message types: `surfaceUpdate`, `DataModelUpdate`, `beginRendering`, and `deleteSurface`.

## Core Concepts

Two principles guide the protocol's design:

1.  **Separation of Concerns:** The UI's **structure** (components) is managed independently from its **state** (data). This allows for efficient state updates without resending the UI definition.
2.  **Progressive Rendering:** The client can render the UI incrementally as it receives messages.

## Key Messages

### 1. `surfaceUpdate`

This message defines the structure of the UI. It contains a list of components, such as text fields, buttons, or layout containers, each with a unique ID. The client processes these component definitions upon receipt.

### 2. `DataModelUpdate`

This message provides the state for the UI. It updates a client-side JSON data model that components can bind to. For example, a `DataModelUpdate` can specify the text for a label or the URL for an image.

### 3. `beginRendering`

This message signals the client that it is permitted to start rendering a UI surface. The timing of this message determines the rendering behavior.

### 4. `deleteSurface`

This message instructs the client to remove and destroy a specific UI surface, freeing up associated resources. This is typically used when a UI is no longer needed.

[gemini-code-assist]

It's a common convention to add a newline at the end of text files. This helps prevent issues with some tools and file concatenations.

Suggested change

	Future versions of the A2UI specification may deprecate the `beginRendering` message. In such a scenario, `surfaceUpdate` messages would render immediately upon receipt, with a default root component ID assumed by the client. This would simplify the protocol by making the progressive streaming model the default behavior.
	Future versions of the A2UI specification may deprecate the `beginRendering` message. In such a scenario, `surfaceUpdate` messages would render immediately upon receipt, with a default root component ID assumed by the client. This would simplify the protocol by making the progressive streaming model the default behavior.