Presentation Model Approach Investigation

### Is your feature request related to a problem? Please describe.

Today JSON Forms holds a minimal central state (`data`, `schema`, `uischema`, `errors`, `renderers`, `config`, `i18n`, `ajv` etc.) and each renderer derives its own props on every render via `mapStateToControlProps` / `ctxTo*Props` / HOC chains. Consequences:

- **Logic leaks into the "UI" layer.** Required-label handling, visibility rules, enablement, error extraction, i18n key resolution, option computation, label derivation, path composition, etc., live in the mappers. Some renderers need more information and additionally access the central state to extract more information.
- **Customization is coarse-grained.** To customize cross-renderer functionality, e.g. change the "label" computation, you often need to override every renderer.
- **Performance can be improved** Every form change re-runs all mappers (e.g. `mapStateToControlProps`) and thereby does path/schema/error work that could be memoized at a layer higher. The existing approach can be improved but might be more natural with a different approach.

We want to evaluate consolidating this logic into a **centralized presentation model** that lives in `@jsonforms/core`. Renderers become thin views over a single PM node.

### Describe the solution you'd like

### Core idea

The core builds and maintains a **list of Presentation Nodes** that mirrors the rendered form. Each node is framework-agnostic and carries **everything a renderer needs to render itself**: its resolved label, translated description, current data slice, error messages, visibility, enablement, and for containers all relevant information of their children.

### Presentation Model construction

The presentation model is constructed by a **builder pipeline** that takes the current state and produces the presentation model. The presentation model is created on the expected visual representation, i.e. it will avoid endless recursive layouts by stopping once the edges of `data` are reached.

For every form change, the presentation model is updated, making sure to keep object identities for unchanged nodes. To actually gain performance compared to the current approach, we need a mechanism for partial updates instead of a full re-generation

### Extensibility

- Renderer customizations work as before. Testers work against presentation nodes.
- Presentation model construction and updating should also be customizable, to allow straightforward cross-cutting customization
- JSON Forms could offer multiple builder pipelines, allowing to configure a schema format (e.g. JSON Schema, zod) and validation (e.g. AJV)

### Backward compatibility

We could continue to offer the existing mappers and testers as a compatibility layer if it's worth it.

### Key benefits

- The presentation model abstracts over the JSON Schema, enabling an easier integration with JSON Schema less approaches
- Clear separation between logic and rendering allows further integrations, e.g. exposing concise state of the form for AI agents, and more generic renderers

### Describe alternatives you've considered

The first step is an evaluation whether this approach makes sense to be implemented at some point. We do not know yet whether we will actually go for this and whether the backward incompatibility and effort are worth it for the supposed gains.

### Package

Core