Prefer OTLP object fields over attributes on ingest

[cartermp]

Today, we can overwrite actual OTLP fields with attributes that have the same name. For example, name is how Honeycomb tracks a span name, but if you have a custom field called name, then this overrides the span's name on the event that we create.

Because of how Honeycomb's event model works, events are just a collection of fields, and we don't distinguish between those that came from OTLP vs. those that are attributes. And in our code, we first copy over the OTLP fields, and then the attributes. The attributes can override.

We should copy over the OTLP fields at the end instead. This has the downside of technically being a breaking change -- however, the reason for overriding these names may not be intentional by users.

[bixu]

Using the K8s Attributes Processor from the Collector, we had a team add a name label the pods of a service. This resulted in all spans being named the pod name in traces, because the Processor had copied the pod label to a resource attribute, and then in the UI that resource attribute, name, overwrote the name being sent as a Span attribute by the service.