Rename the ABI Compatible Data Types component

## Motivation

The current name, **ABI Compatible Data Types**, describes an important technical property, but it is not the clearest name from an application developer's perspective.

The component provides fixed-size, pointer-free data types whose memory layout can be interpreted consistently by Rust and C++ applications. Its primary use case is zero-copy exchange of data across a language and process boundary. The name should communicate this user-facing contract more directly.

"ABI compatible" is compiler and systems-programming terminology that can be interpreted broadly as ordinary C/C++ ABI compatibility or FFI support. It does not clearly communicate that these types define a shared, fixed memory layout across languages. Conversely, implementation terms such as "inline" (seen in current Rust implementation) describe the storage mechanism, but not the cross-language layout guarantee.

A clearer component name would improve:
- discoverability for Rust and C++ application developers;
- consistency between the documentation component, Rust crate, C++ namespace, and public type names;
- separation of the public cross-language contract from reusable inline-storage container implementation details.

## Scope

Identify and apply a new name for the component and its public API surface.

This includes assessing the corresponding documentation component folder, Sphinx-Needs IDs and tags, Rust crate name, C++ namespace, Bazel labels, and references to the component.

This rename must not change the defined binary layout, runtime behavior, or supported data types.

## Acceptance Criteria

- [ ] A name is agreed that describes the component's cross-language fixed-layout contract clearly.
- [ ] The selected name is suitable for both Rust and C++ users.
- [ ] The naming distinguishes the public data contract from the internal inline-storage implementation.
- [ ] All affected documentation, identifiers, tags, and references are updated consistently.
- [ ] The rename preserves existing ABI/layout requirements and does not introduce a behavioral change.