Add base class and infrastructure support for JUnit5/Jupiter

[dweiss]

This patch adds a new class LuceneTestCaseJupiter, which can be used as a direct replacement for LuceneTestCase to convert test classes to JUnit5/jupiter.

The test-framework module exports both junit4 and junit5/jupiter
dependencies. LuceneTestCase remains the parent abstract class for JUnit4 tests.
LuceneTestCaseJupiter is the parent class to extend from for JUnit5
support.

please read

There are some key things to observe here:

• If you decide to inherit from LuceneTestCaseJupiter, all test cases must be proper Jupiter tests, typically this means
  methods must be annotated with @Test. Method prefix
  test* is not sufficient. Methods that are named test* but are not tests
  will cause validation errors at runtime (there is a test for this...).
• You can use parameterized tests, dynamic tests, etc. All these are supported.
• You must not call the static random() method on the parent
  class, even though it is there. Add a Random parameter to your test methods
  or callbacks - it will be automatically injected by the test framework. See the memory
  module tests for some examples.
• Use @BeforeEach, @AfterEach and other junit5-specific callback
  annotations instead of setUp and tearDown methods. These methods are also there, but they should be deprecated and removed at some point.
• Static utility methods have been pulled up to a parent class
  called LuceneTestCaseParent but you should reference them either
  without an explicit type or via the type of the parent class
  for your test framework of choice. The parent class may be removed in the future.

This patch should work as a drop-in-replacement for any subproject using test-framework. A lot of (human) thought went into making sure both the junit4 and junit5 base class work pretty much the same way (there are still some pieces missing but they are not critical).

what next?

Now, if we want to move forward and actually convert all the existing tests to junit5 (and eventually drop junit4) this becomes a more problematic issue because it affects all the downstream projects (solr, elasticsearch) - any tests inheriting from test framework util's "base" classes (like the base class for token filters, etc.) will require updating. If they do non-trivial things, the update may be non-trivial too.

discussion

It took me an enormous amount of time to get this to work with both frameworks at the same time. Not everything is pretty internally but I don't see how certain things can be solved while keeping backward compatibility (and without changing a lot of existing codebase).

Now... For all the benefits junit5 provides (there are many nice things about it), I also think there is not that much visible improvement... I mean - for all the bells and whistles of junit5, it's still just a test framework for running test cases. We can't utilize parallel tests (because we use static contexts everywhere), we don't really do any fancy things. It's mostly the same. If you think this is complicating things with no clear benefit, please do speak up.

[dweiss]

Relate: #13523