Add mechanism for accessing package-privates via invokedynamic instrumentations

[JonasKunz]

Inlined instrumentations sometimes needs to access package-private variables, which are in a different package than the instrumented classes. Here are some examples:

• rx __OpenTelemetryTracingUtil
• lettuce OtelCommandArgsUtil

In #8999 I suggested a way of legally generating MethodHandles to such members via java.lang.instrument (PoC Implementation). However, it seems like most of these package-private accessors come from library instrumentations, which therefore can't assume access to java.lang.instrument.

As a result, if we don't want to allow injection of such accessor classes into the instrumented application classloader, this would mean we would have to implement the access twice most of the times: Once for library instrumentations and once for javaagent instrumentations.

To avoid this duplication I'd suggest we stay with the ability to inject such accessor classes directly into the instrument classloader, even for IndyModules. In order to get rid of shading in the long term, these classes must not use any Otel SDK / API classes, as we don't want to inject those into the bootstrap in the future. However, the mentioned package-private accessor classes are usually dependency free, so this should be fine.

I'd propose to use the API suggested in #9502 for adding this capability to invokedynamic InstrumentationModules:

public void injectClassesToAppClassloader(ClassInjector injector) {
  injector
      .copyClass("my.impl.PackagePrivateAccessor")
      .inject(InjectionMode.CLASS);
}

Subtasks

• add capability to InvokeDynamic InstrumentationModules to inject classes into the instrumented Classloader
• ensure that those injected classes are looked up correctly by the InstrumentationModuleClassloader