Add tests for Kotlin inline value class

[Ogu1208]

Resolves: #5081

Overview

This Draft PR is based on @marcphilipp’s proof-of-concept branch marc/5081-kotlin-value-class-support,
which introduces initial support for Kotlin inline value class parameter resolution.

Currently, the POC supports only kotlin.Result parameters in parameterized tests.
This PR extends the existing test coverage to highlight the current behavior and limitations,
and prepares the ground for supporting arbitrary Kotlin @JvmInline value classes in future updates.

Changes

• Added new test classes under org.junit.jupiter.api.kotlin:
  • MultipleInlineValueClassTest: covers multiple inline and normal parameters in one test.
  • CustomInlineValueClassTest: covers user-defined inline classes (UserId, Email).
  • NullableInlineValueClassTest: covers nullable inline and Result parameters.
• Annotated CustomInlineValueClassTest with @Disabled, since current POC supports only kotlin.Result.
• Intentionally left failing tests in place to demonstrate existing gaps.

---

I hereby agree to the terms of the JUnit Contributor License Agreement.

---

Definition of Done

• There are no TODOs left in the code
• Method preconditions are checked and documented in the method's Javadoc
• Coding conventions (e.g. for logging) have been followed
• Change is covered by automated tests including corner cases, errors, and exception handling
• Public API has Javadoc and @API annotations
• Change is documented in the User Guide and Release Notes

[Ogu1208]

Hi @marcphilipp 👋

Sorry for the delay — this is actually my first attempt at contributing to an open-source project like JUnit,
so I wanted to take a bit of extra time to make sure I understood everything properly before opening this draft.

As discussed in #5081, I’ve based this Draft PR on the marc/5081-kotlin-value-class-support POC branch
and added extended test coverage for Kotlin inline value class parameter resolution.

There are still a few points I’d like to clarify, since I might have misunderstood parts of the earlier discussion:

1. Is the intention for this issue to eventually cover arbitrary @JvmInline classes beyond kotlin.Result?
   (From your earlier comments, it seems like @TWiStErRob might be leading that implementation effort.)
2. For this PR, is it most helpful if I focus solely on test coverage and verification for now,
   or would it be okay to start exploring how kotlin-reflect could generalize the current handling?

I’m happy to adjust the scope based on your guidance.

[Ogu1208]

@marcphilipp 👋
Just wanted to kindly follow up on this — could you please take a look when you have a chance?

[marcphilipp]

Please add an entry to the 6.1.0-M2 release notes.

[marcphilipp]

Is there a good reason to keep this class now that we have the more specific test classes?

[marcphilipp]

Our convention is to suffix test classes with Tests because they contain tests rather than being a test themselves. Please rename the new test classes accordingly.