internal/hostname: Add tracer side hostname detection

[ajgajg1134]

What does this PR do?

This adds a new _dd.tracer_hostname tag which is filled with the tracer detected hostname when the tracer is NOT connected over UDS. Note that a significant amount of this code is a lightly modified version of the code in the datadog-agent's hostname detection logic. Most of the modifications are to reduce complexity / pick "preferred" defaults that can't exist in the agent for legacy reasons. Additionally, this hostname detector can not detect docker/k8s hostnames as most traced apps do not provide access to those APIs (and they aren't provided by default). The "fromContainer" provider is kept so that if this feature is desired for customers who do manually provide access it can later be implemented in the correct place.

Motivation

This will help determine the feasibility of more tracer-level hostname detection for better support of deployments where traced applications do not live on the same host as their agent.

Describe how to test/QA your changes

Manual Testing to be completed in:

• GCP
• Azure
• EC2
• Fargate
• Any Windows machine

Reviewer's Checklist

NOTE! This is a big PR, many files are copied from the datadog agent, primarily with changes made to:

1. Remove any agent dependencies like config, logging etc.
2. Remove legacy options / configuration that in new installations doesn't make sense (Similar to what OTEL hostname detection work did)

Where this is true, files have a comment at the top indicating where they were taken from and what was changed. Feel free to focus your attention on the ones that are new / more heavily modified. In particular I would focus on the providers.go file and the changes in the ddtrace/tracer folder to integrate this new information.

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• Changed code has unit tests for its functionality.
• If this interacts with the agent in a new way, a system test has been added.

[pr-commenter]

Benchmarks

Comparing candidate commit e146954 in PR branch andrew.glaude/HostNameResolution with baseline commit 0ef937c in branch main.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 6 cases.

[katiehockman]

I'll just leave two small driveby comments for the first couple files as I looked at it. It's nice that most of this is in internal/hostname so it's easy to rip out if we end up not wanting to go this route. And just generally helpful for readability 👍

[ahmed-mez]

Suggested change

	if t.config.disableHostnameDetection {
	return hostname.Get()
	}
	return ""
	if !t.config.disableHostnameDetection {
	return hostname.Get()
	}
	return ""

It's often easier and less error prone to have this kind of booleans describe enabling the feature. Any reason why we'd prefer disableHostnameDetection instead of enableHostnameDetection here ?
Even for consistency, all the existing booleans in the config struct describe enabling features/options.