…hange (#4614)

Towards
#4602

Per OTEP:
https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#why-doesnt-this-require-a-major-version-bump

This basically reverts:
-
#3858

Before we did not have a consensus to extend the attribute value types.
However, this has changed with:
-
#4485

Related proto PR:
- open-telemetry/opentelemetry-proto#683

**As a follow-up I plan to create issues in all language repositories so
that they can prepare their APIs and SDKs to extend the attribute value
types.**

---------

Co-authored-by: Trask Stalnaker <[email protected]>

Fixes #4710

OTEP #4485 (Extending attributes to support complex values)

## What

Stabilize the complex `AnyValue` attribute value types and the
corresponding attribute limits.
Simplifiy the Logs Data Model to rely on `AnyValue` and Attribute
Collections instead of custom `any` / `map<string, any>` types.

## Why

Per the OTEP-implementing PR
[#4485](#4485)
tht was merged on **2025‑07‑15**, so the 6‑month window ends around
**2026‑01‑15**. This PR is intended to be merged around **2026‑01‑15**,
in line with that requirement.

> Stable exporters will be prohibited from emitting complex attributes
by default on signals other than Logs until at least 6 months after this
OTEP is merged.

OpenTelemetry **Go** and **Java** treat the common package as a **stable
cross‑cutting surface**. They need these `AnyValue` types and limits to
be Stable in the spec before they can add corresponding features to
their APIs, SDKs, and exporters.

## Prototypes

We have **three independent prototypes** that exercised the complex
`AnyValue` attribute types and limits:

- Java: open-telemetry/opentelemetry-java#7814 (
- Python:
open-telemetry/opentelemetry-python#4587
- Go: open-telemetry/opentelemetry-go#6809


In summary, they:

1. Validated that complex attributes can be represented and processed
end‑to‑end using `AnyValue`.
2. Confirmed that the specified attribute limits (length and count) are
acceptable.
3. Demonstrated that existing implementations can adopt complex
attributes without breaking current stable behavior.

## Other

I was thinking about adding something to `spec-compliance-matrix.md`,
but I do not see any obvious place where it could be located. I think we
can tackle it in a separate PR if there would be a demand for it.

EDIT: Tracked under
#4808