Update ByteBuddy to 1.10.18, adjust to new ByteBuddy gradle plugin

[agoallikmaa]

Updating to ByteBuddy 1.10.18. The motivation is to include the following fix for WebLogic Server:
raphw/byte-buddy#965

In version 1.10.15, ByteBuddy changed how the Gradle plugin works. It is now automatically configured in a way which is incompatible with the current use case, therefore I configure the transformation task from the plugin manually. The specifics are included as comments for the new buildSrc classes, but I will include them in the decription as well:

ByteBuddyPluginConfigurator:
Starting from version 1.10.15, ByteBuddy gradle plugin transformation task autoconfiguration is hardcoded to be applied to javaCompile task. This causes the dependencies to be resolved during an afterEvaluate that runs before any afterEvaluate specified in the build script, which in turn makes it impossible to add dependencies in afterEvaluate. Additionally the autoconfiguration will attempt to scan the entire project for tasks which depend on the compile task, to make each task that depends on compile also depend on the transformation task. This is an extremely inefficient operation in this project to the point of causing a stack overflow in some environments.

To avoid all the issues with autoconfiguration, this class manually configures the ByteBuddy transformation task. This also allows it to be applied to source languages other than Java. The transformation task is configured to run between the compile and the classes tasks, assuming no other task depends directly on the compile task, but instead other tasks depend on classes task. Contrary to how the ByteBuddy plugin worked in versions up to 1.10.14, this changes the compile task output directory, as starting from 1.10.15, the plugin does not allow the source and target directories to be the same. The transformation task then writes to the original output directory of the compile task.

ClasspathByteBuddyPlugin:
Starting from version 1.10.15, ByteBuddy gradle plugin transformations require that plugin classes are given as class instances instead of a class name string. To be able to still use a plugin implementation that is not a buildscript dependency, this reimplements the previous logic by taking a delegate class name and class path as arguments and loading the plugin class from the provided classloader when the plugin is instantiated.

Manually verified that the shadowJar that is built includes the transformed classes.

[iNikem]

@open-telemetry/java-instrumentation-approvers anybody wants to review? Or I will merge today-tomorrow.

[mateuszrzeszutek]

Can we remove this NoOp class if it's no longer used?

[agoallikmaa]

Removed it.

[trask]

I don't really understand the gradle bytebuddy stuff, but I know we've been stuck on an old version of bytebuddy, so really appreciate this!