Basic catalogs should be exported separately from framework adapters

## Problem

A framework adapter should be usable standalone. However, as of right now, all our adapters automatically include the basic catalog:

* [Angular](https://github.com/a2ui-project/a2ui/blob/6930e71d8d61865c18733c85e20d5bbf61a42c31/renderers/angular/src/v0_8/public-api.ts#L18)
* [Flutter](https://github.com/flutter/genui/blob/fc3e775db1fa9a8306decbec9394dee77fed3aba/packages/genui/lib/genui.dart#L14)
* [React](https://github.com/a2ui-project/a2ui/blob/6930e71d8d61865c18733c85e20d5bbf61a42c31/renderers/react/src/v0_8/index.ts#L67)
* [Lit](https://github.com/a2ui-project/a2ui/blob/6930e71d8d61865c18733c85e20d5bbf61a42c31/renderers/lit/src/v0_9/index.ts#L22)

This increases the API surface of the core libraries, and the dependency tree for all apps, even those that do not use the basic catalog. As A2UI is designed to support high trust GenUI experiences, apps would want to have tight control over widgets used in their A2UI catalogs. Having the basic catalog always in the import namespace of your code, however, makes it too easy to use the wrong widget, and too hard to guard against it (it requires deep code analysis with type resolution).

## Options

Instead, developers who would like to reuse some of the basic components should import them from a separate library.

There's a couple of ways to do this decoupling:

1. **Same package, separate libraries**: keep the basic components in the core package, but put them in a separate library. I would recommend this option if our basic components satisfy the following criteria:
a. **Highly reusable**: the core packages should be limited to only highly reusable code, or high value code that cannot exist outside core packages without compromising the design of the core packages.
b. **High quality**: basic components should meet the standard of quality we set for the whole package.
c. **Inherently safe**: basic components should be safe to use, and not pose hallucination, exfiltration, code execution, and other security risks.
3. **Separate packages**: separate basic components into separate packages, requiring not only additional imports, but also additional dependencies (e.g. in `pubspec.yam`, `packages.json`, etc). I would recommend this option if our basic components do not meet the standards set in option 1.

Overall, I have a preference for option 1 same package, separate libraries. This makes A2UI easier to start with, and it is a standard practice for UI toolkits (Flutter, ReactNative, HTML) to include some basics. However, as of right now, other than a few layout primitives, it is unclear how reusable and safe our basic components are. For example, we provide image, audio, and video components, but they do not check the URLs passed to them, which makes them unsuitable for any kind of production deployment. We might have to prune the catalog to something a lot more basic but highly reusable.

La issue indica file di esportazione specifici in renderers/angular, renderers/react, renderers/lit e un pacchetto Flutter. Per prima cosa, esamina come il catalogo di base viene attualmente incluso nel file API/index pubblico di ciascun adapter. Poi, pianifica come separare il catalogo di base nella propria libreria o nel proprio modulo all’interno della struttura dei pacchetti di ciascun framework. «Fatto» significa che ciascun adapter può essere importato senza il catalogo di base e che il catalogo di base è disponibile tramite un percorso di importazione separato.

Scritto dal modello di indicizzazione a partire dal testo della issue.