JUnit: migrate to v5.x

[cagix]

Ich habe mich lange für JUnit 4.x ausgesprochen, u.a. weil sich JUnit5 noch nicht reif für den Praxiseinsatz angefühlte und weil es in JUnit5 keine vernünftige Möglichkeit gab (und gibt), auf Java-Ebene Testsuiten zu definieren (man muss dann über Gradle o.ä. gehen).

Mittlerweile ist JUnit5 aus meiner Sicht reif genug, um zu wechseln. Testsuiten kann man zwar immer noch nur extern formulieren, aber davon machen wir hier im Projekt keinen Gebrauch. Dafür sind die Möglichkeiten zum Testen auf Exceptions sowie für parametrisierte Tests deutlich überlegen im Vergleich zu JUnit4.

Let's switch over.

---

Dieser PR führt die Migration von JUnit 4.x auf JUnit 5.x durch. Betroffen sind:

• Globale Gradle-Konfiguration: Ersetzen der bisherigen JUnit4-Abhängigkeit durch die neue JUnit5-Abhängigkeit plus Launcher (lt. Doku wird letzterer nur für IDEs benötigt, die eine veraltete JUnit-Version mitbringen - brauchen wir die Launcher-Konfiguration überhaupt?!)
• Gradle-Konfiguration für die Subprojekte "game" und "dungeon": Hinzunahme der neuen Abhängigkeiten und Deklaration der JUnit-Plattform für die Tests
• Testsourcen in den Subprojekten "game" und "dungeon":
  • Ersetzen der Importe
  • Übersetzen von @Before und @After durch die neuen Annotationen @BeforeEach und @AfterEach
  • Übersetzen von @BeforeClass und @AfterClass durch die neuen Annotationen @BeforeAll und @AfterAll
  • Übersetzen von @Ignore durch die neue Annotatione @Disabled
  • Übersetzen von @Test(expected = …​) durch den Einsatz von Assertions.assertThrows(...​)
  • Anpassen der Assertions: Es wurde an einigen Stellen assertEquals(string, expected, actual) verwendet. Das gibt es so nicht mehr bzw. der String müsste als letzter Parameter übergeben werden. Da die verwendeten Strings in der überwiegenden Mehrzahl semantisch unklar und nur eine Wiederholung des erwarteten Wertes waren (Beispiel: assertEquals("es sollte 3 rauskommen", 3, something.or.other())), habe ich diese Strings einfach überall entfernt. Es gab einige wenige Stellen, wo die Strings tatsächlich eine sinnvolle semantische Aussage enthielten. Wenn jemand Zeit hat, könnte man diese Strings nochmal wieder einbauen.
  • Der Test contrib.entities.ChestTest.checkCreation() schlägt auf einmal fehl. Wenn ich mir den Test anschaue, frage ich mich, warum der nicht auch bereits in vorher (also in JUnit4) fehlgeschlagen ist? => Issue Dungeon: Test contrib.entities.ChestTest.checkCreation() schlägt fehl #1622 fixed: tausche assertEquals gegen die korrekte Methode für den Use-Case: assertArrayEquals (31391ea).

---

closes #1583

[AMatutat]

lgtm

Hoffe die Tasse Tee war groß genug, sieht ja lästig aus.