Introduce new concept of owning Attributes or Properties on API surface

[maxgolov]

Our Tracing API surface assumes that the common::AttributeValue here does not own the originating event attribute memory.

When I use the SDK to append some event on Span, e.g.

    std::map<nostd::string_view, common::AttributeValue> m;

Then use some utility function that returns a temporary std::string, e.g. std::string getSomeValue()

I cannot code my events this way:

    std::map<nostd::string_view, common::AttributeValue> m;
    m["Key1"] = getSomeValue();
    m["Key2"] = getSomeOtherValue();

Because nostd::string_view would refer to temporary that does not have any lifecycle guarantees.

Now to overcome this limitation, I could do the following:

    std::map<nostd::string_view, common::AttributeValue> m;
    auto val1 = getSomeValue();
    m["Key1"] = val1;
    auto val2 = getSomeOtherValue(); 
    m["Key2"] = val2;

Then emit my span attributes, which would be handled more coherently.

I wonder if we could create another class similar to OwnedAttributeValue in API, maybe naming it EventProperties or Properties or Attributes, being owning collection in order to simplify the usage of OpenTelemetry SDK. Without this concept it is very easy to fall into trap of a memory corruption on a temporary assigned to non-owning nostd::string_view.

As alternative, I'd like to show what could have been done to address this:
https://github.com/maxgolov/opentelemetry-cpp/blob/master/api/include/opentelemetry/event/Properties.hpp

This code is inspired by the following original implementation:
https://github.com/microsoft/cpp_client_telemetry/blob/master/lib/include/public/EventProperties.hpp

[maxgolov]

(there is a glitch in Discussion, it crashed with 404, and the same idea got submitted twice 😁 )

[pyohannes]

The initial motivation for the non-owning KeyValueIterable approach was to avoid using non ABI stable STL types, like std::string or std::vector in the API. Your implementation of Property uses those under the hood, so we couldn't guarantee a stable ABI with that.