Move Akka and Armeria virtual fields to helpers

[JonasKunz]

Part of #13031.

This PR shows with akka as a complex example and armeria as a simple one on which "patterns" I would suggest to use for moving VirtualField.find calls from advice classes to constants:

• If the fields are shared across different instrumentations in the same project, add them to a VirtualFields helper class
• If they are only local to a single advice, use a static nested class in the advice. When we drop support for inlined mode, we can turn those into constants directly in the advice class instead.

This PR is intended as a small starter so that we can discuss the proposed patterns. Based on those, I'll open 2-3 bigger PRs for all remaining usages, luckily there aren't that many.

[JonasKunz]

Until we drop support for inlined advice, both the class and the constant need to be public.
They are accessed directly from the instrumented class, which lives in a different package.

When only indy is support, we can make it a private constant of the advice instead.

[laurit]

I'd say this is probably not worth it. Instead of creating the nested VirtualFields class in advice you are better off encapsulating the virtual field access in a util class that internally uses the virtual field. For example in case of ArmeriaServerCallInstrumentation I should have really added an util class in https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/instrumentation/grpc-1.6/library/src/main/java/io/opentelemetry/instrumentation/grpc/v1_6/internal and done the virtual field access there. It is easier to search from ide where the util class is used instead of searching for something like VirtualField.find(ServerCall.class, String.class). If creating a new util class for the virtual fields feels like an overkill we could add the logic to the Singletons class. I think the separate VirtualFields class is fineish in the akka instrumentation for the task context propagation.

[JonasKunz]

Makes sense, fixed in 0f1460d