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.

L’issue pointe vers des fichiers d’exportation spécifiques dans renderers/angular, renderers/react, renderers/lit ainsi que vers un package Flutter. Commencez par examiner comment le catalogue de base est actuellement inclus dans le fichier d’API/index public de chaque adaptateur. Planifiez ensuite comment séparer le catalogue de base dans sa propre bibliothèque ou son propre module au sein de la structure de package de chaque framework. « Terminé » signifie que chaque adaptateur peut être importé sans le catalogue de base et que le catalogue de base est disponible via un chemin d’importation distinct.

Rédigé par le modèle d'indexation à partir du texte de l'issue.