fix: apply //dd:orchestrion-enabled to tracer-internal modules

[nsrip-dd]

What does this PR do?

The //dd:orchestrion-enabled directive aspect is currently not applied to
tracer-internal modules. dd-trace-go will rely on this directive to detect
whether it was built with Orchestrion. So, set "tracer-internal: true" for the
directive.

Nothing seems to be broken right now. I'm not sure the best way to test this, at
least in this PR. I'm working on an integration test for the profiler when
built with Orchestrion. Once that's up and running, it will break if the
profiler relies on the directive to add Orchestrion-related info. And
presumably once we start relying on goroutine-local storage for context, stuff
will break if the directive doesn't work in dd-trace-go?

Motivation

I happened to notice this was broken while trying to add Orchestrion-related
information to the profiler uploads. The internal/orchestrion.Enabled
function in dd-trace-go was always returning false, even when built with
Orchestrion.

Reviewer's Checklist

• Changed code has unit tests for its functionality.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 61.82%. Comparing base (0922cdc) to head (bc3c198).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #223   +/-   ##
=======================================
  Coverage   61.82%   61.82%           
=======================================
  Files          93       93           
  Lines        5027     5027           
=======================================
  Hits         3108     3108           
  Misses       1592     1592           
  Partials      327      327           

Flag	Coverage Δ
ARM64	45.16% <ø> (ø)
Linux	66.59% <ø> (ø)
Windows	43.83% <ø> (ø)
X64	61.82% <ø> (ø)
generator	42.71% <ø> (ø)
go	51.52% <ø> (ø)
go1.22	45.16% <ø> (ø)
go1.23	44.94% <ø> (ø)
integration	46.26% <ø> (ø)
macOS	45.16% <ø> (ø)
unit	40.84% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nsrip-dd]

@eliottness The integration tests are failling with this change. Example. I think it's due to this part in dd-trace-go:

type contextStack map[any][]any

// getDDContextStack is a main way to access the GLS slot of runtime.g inserted by orchestrion. This function should not be
// called if the enabled variable is false.
func getDDContextStack() *contextStack {
	if gls := getDDGLS(); gls != nil {
		return gls.(*contextStack)
	}

	newStack := new(contextStack)
	setDDGLS(newStack)
	return newStack
}

The new(contextStack) call gives you a non-nil pointer to a nil map. So the methods later check that the receiver s *contextStack is not nil, but that just means the pointer isn't nil. There needs to be a make call to actually create the map. I think adding *newStack = make(contextStack) would work?

[RomainMuller]

This particular fix is also present in #225, which also includes a monkey-patch for the current issue in dd-trace-go.

[RomainMuller]

This actually needs #232 before the CI will consistently pass; it is currently flaky due to re-use of improperly cleaned up g objects.