Fix modularized applications having a dependency version conflict

[jackshirazi]

discussion in https://discuss.elastic.co/t/apm-java-agent-v1-27-0-instrumention-errors-on-modulepath/292877

Describe the bug

When a modularized application (ie uses module-info.java, the Java Platform Module System JPMS) has a dependency that the agent also has, it look like the module specified dependency is first resolved by all classloaders because that's how the module system is implemented. For the agent to have isolated dependencies, it seems we need to use module layers

Steps to reproduce

Per the example in the discussion thread - a basic hello world spring-boot modularized application

Expected behavior

In this case spring-boot has a dependency on byte-buddy version 1.11.22, while the agent has a dependency on version 1.12.3, but version 1.11.22 is loaded and used by the agent, resulting in stack trace errors and feature failure. Lines in the stack traces would include many entries like

   at net.bytebuddy@1.11.22/net.bytebuddy....

[jackshirazi]

note the reason we didn't see this before 1.28 was prior to 1.27 we shaded the agent dependencies so they were actually different package names

[jackshirazi]

I succeeded in implementing an integration test with a dockerized container, here https://github.com/jackshirazi/apm-agent-java/tree/test-for-2373 under integration-tests/spring-boot-2-6-2. Not yet added the assertion that fails but everything else is there