Release Note: JFR Event for @Deprecated Methods

A new JFR event, `jdk.DeprecatedInvocation`, has been added to JDK 22 to help users detect their use of deprecated methods located in the JDK.

To record these events in JFR, a user must specify a recording on the command line, like `-XX:StartFlightRecording`. Starting a recording during runtime, for example, using `jcmd` or the JFR Java API, will not have these events reported unless `-XX:StartFlightRecording` is specified on the command line.

An example event would be rendered like this using the JFR tool:
```
bin/jfr print <recording.jfr>

jdk.DeprecatedInvocation {
  startTime = 23:31:28.431 (2023-12-04)
  method = jdk.jfr.internal.test.DeprecatedThing.foo()
  invocationTime = 23:31:25.954 (2023-12-04)
  forRemoval = true
  stackTrace = [
    jdk.jfr.event.runtime.TestDeprecatedEvent.testLevelAll() line: 96
    ...
  ]
}
```
The current design will only report direct method invocations where the caller resides outside the JDK. Intra-JDK invocations will not be reported. Additionally, invoking methods declared deprecated but located outside of the JDK, for example in a third-party library, will not be reported, at least not during this first implementation. This might change in the future.

There exists a small restriction in the reporting of invocations from the Interpreter. In the situation where two caller methods are members of the same class, and they invoke the same deprecated method, for example:
```
public class InterpreterRestriction {
    public static void main(String[] args) {
        invoke1();
        invoke2();
    }
    private static void invoke1() {
        System.getSecurityManager();
    }
    private static void invoke2() {
        System.getSecurityManager();
    }
}
```
In this situation, only `<InterpreterRestriction.invoke1, System.getSecurityManager>` will be reported because the Interpreter implementation will consider `System.getSecurityManager()` to be resolved and linked after the first call. When `invoke2()` is called, no slow path will be taken for the resolution of the `System.getSecurityManager()` method because it is already resolved as part of the cpCache. This restriction does not exist in C1 or C2, only in the Interpreter.

When analyzing the reported events, checking all methods in the reported class is recommended. This slight restriction can be resolved using an iterative process; if one call site is fixed, the other will be reported in the next run.