Support maps and heterogeneous arrays as attribute values

Resolves open-telemetry#376

Use cases where this is necessary or useful:

1. Specify more than one resource in the telemetry: open-telemetry#579
2. Data coming from external source, e.g. AWS Metadata: open-telemetry#596 (comment)
   or open-telemetry#376 (comment)
3. Capturing HTTP headers: open-telemetry#376 (comment)
4. Structured stack traces: open-telemetry#2841
5. Payloads as attributes: open-telemetry/oteps#219 (comment)

This is a draft PR to see what the change looks like.

If this PR is merged it will be nice to follow it up with:
- A standard way of flattening maps and nested objects when converting from OTLP
  to formats that don't support maps/nested objects.
- Recommendations for semantic conventions to use/not use complex objects.

specification/common/README.md

@@ -27,12 +27,16 @@ aliases: [/docs/reference/specification/common/common]
 An `Attribute` is a key-value pair, which MUST have the following properties:
 
 - The attribute key MUST be a non-`null` and non-empty string.
-- The attribute value is either:
+- The attribute value can be of `any` type, where any is defined as one of the following:
   - A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer.
-  - A homogeneous array of values of primitive type.
-  - An array of any attribute values [since 1.15.0].
-  - A key/value map, where key is string and value is any attribute value [since 1.15.0].
-
+  - A homogeneous array of values of primitive type [before 1.19.0].
+  - An array of `any` values [since 1.19.0].
+  - A key/value map, where key is string and value is `any` value [since 1.19.0].
+
+Complex attribute types (such as homogenous arrays, arrays of any, and maps) SHOULD be
+used sparingly, in situations where their use minimizes manipulation of the data’s
+original structure.
+
 When exporting to protocols that do not natively support a particular non-string
 value type the following conversion SHOULD be performed: