Implemented factory for generating invokedynamic proxy classes

[JonasKunz]

The recently added invokedynamic-based InstrumentationModule mechanism changes where helper classes are loaded:
Previously, helper classes were injected into the application classloader. With the new mechanism, they instead are loaded in an isolated InstrumentationModuleClassloader. While this helps us with the long-term goal of removing shading and improving isolation and debugability of instrumentations, there are some instrumentation where the application classloader actually needs to see certain helper classes.

I've identified the following cases by looking at InstrumentationModules which register helper resources:

• AWS SDK instrumentation injecting TracingExecutionInterceptor
• Azure SDK instrumentation injecting various service providers
• Apache Dubbo instrumentation injecting a Filter
• Log4J2 instrumentation injects OpenTelemetryContextDataProvider
• Spring actuator instrumentation injects OpenTelemetryMeterRegistryAutoConfiguration
• Spring Web instrumentation injects OpenTelemetryHandlerMappingFilter

We can't just stay with injecting those classes directly: They make use of Otel-SDK/API classes, which we want to remove from the bootstrap in the long term in order to get rid of shading.

To allow the migration of those InstrumentationModules to invokedynamic, I've started implementing the proxy approach suggested in this discussion.

The idea is to not inject the classes listed above directly, but instead to inject runtime-generated proxies for those classes.
These proxies do not have any direct dependency on classes provided by the agent and therefore can be injected without requiring anything from the bootstrap. The "original" classes for which the proxies are generated are loaded in the InstrumentationModuleClassloader and invoked from the proxy classes via invokedynamic.

This PR only adds the proxy generation and corresponding unit tests. It does not yet add the functionality to InstrumentationModules.
This will be added with a follow-up PR. I'm thinking of adding a new method to InstrumentationModule, which could look somewhat like this:

public void injectClassesToAppClassloader(ClassInjector injector) {
   injector
       .createProxy("my.impl.ImplClass", "name.of.generated.Proxy")
       .inject(InjectionMode.CLASS_AND_RESOURCE);
}

The suggested API should be muzzle friendly and would allow us to extend the functionality in the future without having to introduce more new methods to InstrumentationModule.

[laurit]

I think this is fine for start. Testing this on the real instrumentations should show whether this will work or not.