Migrate ResourceTests to JUnit 4/5

[HeikoKlare]

The ResourceTest class is implemented by several resource-related test classes. The ResourceTest class is tied to JUnit 3, such that all derived test class also have to stick to JUnit 3.

Due to the high amount of tests relying on the class (including session tests that use a specific test runner that currently also relies on JUnit 3), migration to JUnit 4 has to happen incrementally to avoid a huge RP with a high risk of errors. One impediment is the test class hierarchy given by JUnit 3. Precisely, ResourceTest contains a bunch of utility methods that could/should actually be placed in an independent utility class, so that using these utilities does not enforce the embedding of a test class into a specific type hierarchy. This is also the pattern used for assertions, which were provided via inheritance in JUnit 3 and were moved to dedicated assertion classes in JUnit 4. Functionality in ResourceTest that is stateful, as well as common setup/cleanup functionality, can be placed in test rules (JUnit 4) or extensions (JUnit 5).

I have already started with preparatory refactorings to remove JUnit-3-specific functionality from test classes, such as using fail for failing with an exception rather than throwing the exception by the test method.
I will do the following to incrementally migrate the ResourceTests:

• Move all utility functionality from ResourceTest into a utility class
• Move all stateful and setup/cleanup functionality from ResourceTest into test rules
• Incrementally remove inheritance of all ResourceTest specializations and migrate them to JUnit 4
• Replace the SessionTestSuite and all session tests with a JUnit-4-conforming implementation

Upcoming PRs will target these goals. In case you have objections to the procedure, please let me know.

One point I want to mention explicitly: one might argue for inheriting utility methods as a matter of convenience, but the current complexity to migrate the tests shows how unmaintainable it is to use inheritance for providing utilites, as it forces you to use a specific type hierarchy to use utilty functionality.