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.

该 issue 指向 renderers/angular、renderers/react、renderers/lit 中的特定导出文件，以及一个 Flutter package。首先，检查当前每个 adapter 的公共 API/index 文件是如何打包基本 catalog 的。然后，规划如何在每个 framework 的 package 结构中，将基本 catalog 分离到其自身的 library 或 module 中。“完成”意味着每个 adapter 都可以在不包含基本 catalog 的情况下被 import，并且基本 catalog 可通过单独的 import path 获取。

由索引模型根据 Issue 内容生成。