[Entitlements] Implement entry point definitions via checker function signature

[ldematte]

This PR implements automatic entry-point description for Instrumenter, implementing Option 1 from Entitlement checks and entry-point definition.

It introduces one annotation (@InstrumentationTarget) to use on EntitlementChecker methods to specify which method in the JVM the check is targeting. The annotation will be used to populate a MethodKey, like before.

This PR also changes the way to describe the checker method to inject in the target prologue: before, it was a java.reflect.Method, now it's simple record named CheckerMethod.
This is because we decided to avoid using reflection, and use ASM to scan and find functions, so to avoid any chance of loading additional types before instrumentation.

EDIT:
After discussing options we the team, we came up with the idea to avoid using annotations and try and express everything in one place (in this case, the function signature, name + arguments).
The name and arguments of the checker will directly point to the class/method to instrument (always by populating a MethodKey, like before.

Examples:

void check$org_example_SomeClass$staticMethod(Class<?> callerClass, int arg)
--> static staticMethod(int) in org.example.SomeClass 

void check$$method(Class<?> callerClass, org.example.SomeClass that, int arg)
--> method(int) in org.example.SomeClass 

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[prdoyle]

First initial pass. I'm intending to take a second look...

[prdoyle]

The annotation name @InstrumentationTarget will be inconsistent with the terminology the code currently uses. We have:

• The "instrumentation" or "check" method is the method in EntitlementChecks. (Going forward, I think the term "check" is probably preferred here.)
• The "target" method is the method into which the instrumentation is inserted

In an earlier branch of mine, I used the name @CheckBefore. I think some variation of the word "check" would be preferable to "target". Perhaps just @Check?

[ldematte]

As discussed in the sync, removed annotations in favour of "name mangling", i.e. using only the function signature (name + arguments) to identify the method to instrument.
We can always re-introduce annotations at a later phase if e.g. we need to override this behaviour, like expressing names that do no play well with our mangling.

[ldematte]

@elasticmachine update branch

[prdoyle]

Just some debatable style comments. If you disagree with all of them, I think this is mergeable as-is. 😂

[prdoyle]

Huh, that's kind of clever, but I'm torn on it. On the one hand, this reduces redundancy because the class could already be derived from the argument list in the case of an instance method. But on the other hand, a uniform name-mangling convention seems desirable too. 🤔

[elasticsearchmachine]

💔 Backport failed

Status	Branch	Result
❌	8.18	The branch "8.18" is invalid or doesn't exist

You can use sqren/backport to manually backport by running backport --upstream elastic/elasticsearch --pr 116754