Add bytes (binary) as a data type to AnyValue (#297)

Contributes to:
open-telemetry/opentelemetry-specification#780
open-telemetry/opentelemetry-collector-contrib#3267

Issue open-telemetry/opentelemetry-specification#780
nicely describes why the data type is needed. There are several use cases
for binary data, both for trace and log attributes and for log record Body.

This is a backward compatible addition. After this change is merged no senders
will initially exist that emit binary data. Nevertheless, if such data is received
by the Collector it will correctly pass such data intact through the pipeline
when receiving/sending OTLP (no Collector code changes are needed for this).

We do not yet have binary data type in the OpenTelemetry API, so no existing
sources can emit it yet.

The receivers that do not understand the binary data type should also continue
functioning normally. Collector's current implementation treats any unknown
data type as NULL (and this would apply to binary data type until we teach
the Collector to understand binary specifically). I checked the Collector source
code and this should not result in crashes or overly surprising behavior
(NULL is either ignored or treated as an "unknown" branch in the code which
does not care about it).

We will add full support for binary data to the Collector, particularly to
support translating it correctly to other formats (e.g. Jaeger, which supports
binary type natively).

Note: the addition of this data type to the protocol is not an obligation to
expose the data type in the Attributes API. OTLP has always been a superset of
what is possible to express via the API. The addition of the data type in the
Attributes API should be discussed separately in the specification repo.

opentelemetry/proto/common/v1/common.proto

@@ -34,6 +34,7 @@ message AnyValue {
     double double_value = 4;
     ArrayValue array_value = 5;
     KeyValueList kvlist_value = 6;
+    bytes bytes_value = 7;
   }
 }