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.

The issue points to specific export files in renderers/angular, renderers/react, renderers/lit, and a Flutter package. First, examine how the basic catalog is currently bundled in each adapter's public API/index file. Then, plan how to separate the basic catalog into its own library or module within each framework's package structure. 'Done' means each adapter can be imported without the basic catalog, and the basic catalog is available via a separate import path.

Written by the indexing model from the issue text.