Extend the set of attribute value types

[pellared]

Changes

• Introduce of AnyValue type supporting complex data structures (empty value, byte arrays, heterogeneous arrays and maps).
• Consolidate of attribute definitions across signals to use the unified AnyValue type.
• Update attribute limits to accommodate new value types.
• Allow attribute collections to contain duplicate keys via an opt-in configuration (as this is allowed for log attributes).
• Remove "standard attribute" terminology in favor of general "attribute".

Extend attribute types

Prior-art (this PR guides towards this): #4636

Prototype: open-telemetry/opentelemetry-go#6809

Follows #4614

Related to #4602

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

https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#how describes how languages should add support for new attribute value types.

Closes #4460 (no longer needed - feature is removed)

OTEP changes

Notice that this PR has changed the strategy for https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#api from:

OTel API MAY support setting complex attributes on metrics, resources, instrumentation scope, span events, and as identifying entity attribute

to simply:

OTel API MUST support setting complex attribute.

This is the agreement up to this point: #4651 (comment)

The other change in the OTEP is because of #4651 (comment).

Attribute limit updates

Towards #4487

This also proposes minimal and non-breaking additions for the attribute limits: https://github.com/open-telemetry/opentelemetry-specification/blob/main/oteps/4485-extending-attributes-to-support-complex-values.md#attribute-limits.

The proposal for attribute count limit is proposed because of #4651 (comment).

• Predictability: Users can more easily understand and predict when they'll hit the limit. Especially given the existing behavior of attribute count limit.
• Practical usage: Maps are typically used as cohesive units of related data, so counting them as single attributes aligns with their semantic purpose. Without this rule, a single map attribute with many internal key-value pairs could quickly exhaust the attribute count limit, which would be surprising behavior for users.

The proposal for attribute value length limit seems the most logical to me.

Comments to be addressed as followups

I am going to create issues to be created after this is PR merged:

• Extend the set of attribute value types #4651 (comment)
• Extend the set of attribute value types #4651 (comment)
• Extend the set of attribute value types #4651 (comment)

[austinlparker]

We'd like to get this merged today. If there's no further feedback by log sig meeting we'll merge

[chalin]

Link checking is failing because this section has been removed, see https://github.com/open-telemetry/opentelemetry.io/actions/runs/18904968462/job/53961074422

docs/languages/java/api/index.html
  hash does not exist --- docs/languages/java/api/index.html -->
    /docs/specs/otel/common/#standard-attribute

What should be used as an alternative to common/#standard-attribute? I don't see any mention of standard attributes in the page anymore. Here is an excerpt of the markdown with that link:

### Attributes

[Attributes](https://www.javadoc.io/doc/io.opentelemetry/opentelemetry-api/latest/io/opentelemetry/api/common/Attributes.html)
is a bundle of key value pairs representing the
[standard attribute definition](/docs/specs/otel/common/#standard-attribute).
`Attributes` are a recurring concept in the OpenTelemetry API:

/cc @open-telemetry/docs-approvers

[chalin]

Let's track this via:

• [editorial] Link checking is failing because of deleted heading and section #4712