Update for E&S

[vreynolds]

Is your feature request related to a problem? Please describe.

Environments & Services are coming to Honeycomb. The beeline should be updated to support sending data to environments while maintaining backward compatibility. To achieve this, we will set dataset from service name, and provide appropriate warnings depending on environment vs. non-environment teams.

Describe the solution you'd like

Tracing scenario for environment-aware teams:

• Dataset should no longer propagate across services for new environment key.
• ServiceName "required"†. If unset, will warn and set service_name AND service.name to unknown_service:<process> or unknown_service:language. Service name is used to populate dataset name; if unknown_service.* then truncate tounknown_service for dataset name. service.name field will be added to the already added service_name for closer consistency with OTel.
• WriteKey required. If unset, will warn.
• Dataset ignored. If unset, no warning (because no longer used). If set, will warn to clarify that it will be ignored in favor of service name.

Tracing scenario for legacy (non-environment-aware) teams:

• ServiceName "required"†. If unset, will warn.
• WriteKey required. If unset, will warn.
• Dataset required. If unset, will warn and default to beeline-<language>.

† While not technically required, service name is highly encouraged to avoid unknown_service and to instead properly describe the data being sent to Honeycomb (and the data being viewed in Honeycomb UI).

This will be addressed in a separate issue/PR: Set spanKind value based on OTel spec for consistency across beelines and OTel.

Notes from decision around defaulting when no service name is provided:

Given a beeline configured with a v2 api key and without a service name
When it sends HNY events
Then it should use unknown_service as the dataset
And it should use unknown_service:process-name as service_name

When given a legacy key, the behavior remains the same as today.

Notes on trimming whitespace