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.

A issue aponta para arquivos de exportação específicos em renderers/angular, renderers/react, renderers/lit e para um pacote Flutter. Primeiro, examine como o catálogo básico é atualmente incluído no arquivo de API/índice público de cada adaptador. Em seguida, planeje como separar o catálogo básico em sua própria biblioteca ou módulo dentro da estrutura de pacotes de cada framework. “Concluído” significa que cada adaptador pode ser importado sem o catálogo básico e que o catálogo básico está disponível por meio de um caminho de importação separado.

Escrita pelo modelo de indexação a partir do texto da issue.