Labels vs Intake for service-specific fields

Many services have information that is valuable to users when included in span/transaction documents. For example, [we want to attach the S3 bucket and object keys](https://github.com/elastic/apm/issues/759) to S3 spans. In PHP, users would like to have the Wordpress Theme attached to transactions.

For this discussion we're not talking about fields that will be used in the UI. Those should always be standardized in the intake spec. Instead, these are extra pieces of data that will be present in the documents should users need them, and can be used for custom dashboarding.

### Labels

Pros:
- Adding a new label does not require a new version of the intake/APM server -- fields added this way are immediately available to users
- Reduces bloat in the intake spec

Cons:
- Labels have historically been reserved for users (though this is a gray area with the OTLP intake, which maps extra attributes to labels)
- Labels do not enforce consistency across agents

### Intake

Pros:
- Enforces consistency across agents
- Reserves labels for users (again, a gray area due to our OTLP mapping)

Cons:
- "Expensive" to add -- have to add to intake and then wait for next Server version
- Adding service-specific fields will decrease the intake's adherence to ECS
- Spec bloat due to potentially hundreds of service-specific fields in the long term (Otel has almost 30, just for DynamoDB)

### Other alternatives

- Add a label-like namespace that is not exposed to the user, which would keep these new fields separate from the user-controlled label namespace, while allowing for label-like flexibility.

---

Thoughts?

/cc @felixbarny @AlexanderWert @gregkalapos @estolfo