Clarify non-OTLP representation guidance nested AnyValue

[pellared]

Why

Per #5028 (comment)

The previous wording only called out a few special nested cases, such as byte arrays, empty values, and special floating point values. This made the array and map sections less explicit than the top-level AnyValue representation guidance.

The updated wording keeps the same intended representation, but makes the nested rules clearer and avoids duplicating full guidance between arrays and maps.

What

Clarifies how nested AnyValue values are represented in the non-OTLP representation guidance for arrays and maps.

This PR:

• makes the array representation explicitly link to JSON arrays;
• documents how each nested AnyValue type should be represented as a JSON value;
• clarifies that map keys are JSON string member names;
• clarifies that map values follow the same representation rules as array elements;

[Copilot]

Pull request overview

This PR refines the “AnyValue representation for non-OTLP protocols” guidance to make nested AnyValue encoding rules inside arrays and maps explicit and consistent with JSON semantics.

Changes:

• Make array encoding explicitly align with JSON arrays and enumerate JSON representations for each nested AnyValue type.
• Clarify map encoding as JSON objects, including that keys are JSON member names and values follow the same rules as array elements.
• Add an Unreleased changelog entry for the documentation clarification.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
specification/common/README.md	Expands nested AnyValue representation rules for arrays/maps using explicit JSON mappings.
CHANGELOG.md	Adds an Unreleased note documenting the clarification.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.