Improve Javadoc of ApplicationEvents to clarify preferred usage

This commit reorders and clarifies the usage instructions for
ApplicationEvents to:

1. Recommend method parameter injection as the primary approach, since
   ApplicationEvents has a per-method lifecycle
2. Clarify that ApplicationEvents is not a general Spring bean and
   cannot be constructor-injected
3. Explicitly state that field injection is an alternative approach

This addresses confusion where developers expect ApplicationEvents to
behave like a regular Spring bean eligible for constructor injection.

See gh-35297
Closes gh-35335

Signed-off-by: khj68 <[email protected]>

Author: khj68

spring-test/src/main/java/org/springframework/test/context/event/ApplicationEvents.java

@@ -33,12 +33,14 @@
  * to be manually registered if you have custom configuration via
  * {@link org.springframework.test.context.TestExecutionListeners @TestExecutionListeners}
  * that does not include the default listeners.</li>
- * <li>Annotate a field of type {@code ApplicationEvents} with
+ * <li>With JUnit Jupiter, declare a parameter of type {@code ApplicationEvents}
+ * in a test or lifecycle method. Since {@code ApplicationEvents} is scoped to the
+ * lifecycle of the current test method, this is the recommended approach.</li>
+ * <li>Alternatively, you can annotate a field of type {@code ApplicationEvents} with
  * {@link org.springframework.beans.factory.annotation.Autowired @Autowired} and
- * use that instance of {@code ApplicationEvents} in your test and lifecycle methods.</li>
- * <li>With JUnit Jupiter, you may optionally declare a parameter of type
- * {@code ApplicationEvents} in a test or lifecycle method as an alternative to
- * an {@code @Autowired} field in the test class.</li>
+ * use that instance of {@code ApplicationEvents} in your test and lifecycle methods.
+ * Note that {@code ApplicationEvents} is not a general Spring bean and is specifically
+ * designed for use within test methods.</li>
  * </ul>
  *
  * @author Sam Brannen