[test-stack] Implement inner class assertion and fix typo "doesNotContains"

[Philzen]

After some hours of wrestling Generics, this finally works as intended and mainly adds the following:

• capability to run assertions on inner classes to JavaFileAssert
• short-hand methods hasAnnotation(String) and doesNotHaveAnnotation(String) to MethodAssert and the new InnerClassAssert (these can be used to avoid writing .assertMethodAnnotations().containsWithName(String) and .assertMethodAnnotations().doesNotContainWithName(String), respectively.

Also did changes to harmonize and improve our JavaFileAssert API:

• fixed the typo …doesNotContains… (that has been triggering my inner Monk for many time :smile: )
• assertion classes that extend ListAssert are now pluralized (i.e. MethodAnnotationsAssert instead of MethodAnnotationAssert) to make it easier to understand whether you are asserting on a collection or an actual element
• made method names consistent: assertSomething(…) now always returns a new assertion object (going one level deeper), while hasSomething(…) returns the same object (staying on the same level)

In general, there is more about this API that should be harmonized, but for starters i'm happy.

PR checklist

• [x] Read the contribution guidelines.
• [x] Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• [ ] Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh ./bin/configs/*.yaml
  ./bin/utils/export_docs_generators.sh

  (For Windows users, please run the script in Git BASH) Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written tests may be removed.

• [x] File the PR against the correct branch: master (upcoming 7.6.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without fallbacks)
• [ ] If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.

[Philzen]

@wing328 Kindly take a gander. Please merge before #18917 as it builds on the features that are introduced here.

Doing separate PRs as i want to start more clearly separating scope / concerns here, makes things easier in case anything comes up and a revert should be needed.

I was temped to press the merge button myself as i'm confident this PR is a non-critical feature addition to the test stack … however i don't want to take liberties here…

[wing328]

can you please resolve the merge conflicts when you've time? after that i'll get it merged.

[Philzen]

can you please resolve the merge conflicts when you've time? after that i'll get it merged.

Done!

Actually that merge conflict was a stroke of luck b/c i realized the API i introduced did not have the consistency i intended when i tried to apply the added hasAnnotation() short-hand method to the tests that were just merged in #18870 … now it's really beautiful, just look at https://github.com/OpenAPITools/openapi-generator/pull/18921/commits/6af0eaef028cb2fe0f7133250225286fde89b1f3

As part of that, i also harmonized the inconsistency between assert… and has…. Now assert… will always return a assertion object (going deeper), while has… gives back the same (staying on the same level). Writing tests is slowly becoming even more fun :smile:

Updated the PR description and rebased #18917 on this, so that should go through easily.