Initial PlanetGenerator Setup

[IsaiahBlanks]

Description

This PR adds the default implementation of Planets to the new modular world-gen system. It also sets up the game so that SolarSystems and Planets generated by Generator classes show up in the game.

In this implementation, many options are available to the Planet via getting the config in your particular implementation, and then changing various values

Testing

Run the game, and you should see SolarSystems running with Planets in them, but no belts and no mazes. There are two types of SolarSystems that will generate, the default systems and large SolarSystems. Generate a world with a good amount of systems (at least 4) to make sure you see the different types.

Outstanding Work

Two features still need to be added for Planets. One is the ability to place custom objects/ modify terrain, which will involve modularizing the PlanetObjectsBuilder class to accept types of objects, instead of specific objects. The other is the ability to load custom PlanetConfig files. Additionally, tests need to be written still. There is an issue with testing PlanetGenerators as the require the PlanetConfigs class to be loaded, and this seems to be dependent on the class CollisionMeshLoader, which is throwing an error when running tests

[Cervator]

Tests out!

Was able to run the game in my Android Studio setup, although I had to delete my local warp module (incompatible with the worldgen changes, although probably an easy fix). Did get some weird errors from trying gradlew clean buildDebug run but that might just be the workspace. gradlew jar run worked fine after I deleted warp

Can confirm the game runs as described, I started with a few more systems than usual and got a nice big game world, no belts or mazes - which is fine even for merging since there's a target topic branch. Was able to travel to the nearest planet and see it looking pretty normal. One oddity: on my way there I flew by a hostile space station - I think those are limited to the second solar system in the classic setup? With worldgen changing it makes sense some things like that will be thrown off, the starter system should probably be special and have fairly mundane spawning rules.

It might also help this PR with a quick description of a test that'd vary a planet or planet type, although that may well be more for a tutorial like Terasology's worldgen one :-)

I did eventually crash, after arriving at a different solar system and heading toward a planet there, with a java.lang.AssertionError: normalizing NaN angle - DS code tends to crash rather overly hard with these assertion errors over even tiny things. We probably have existing bugs floating around still that cause the issue, but maybe this is new since the stacktrace includes some planet gen. Full stacktrace:

com.badlogic.gdx.utils.GdxRuntimeException: java.lang.AssertionError: normalizing NaN angle
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:117)
    at org.destinationsol.desktop.SolDesktop.main(SolDesktop.java:149)
Caused by: java.lang.AssertionError: normalizing NaN angle
    at org.destinationsol.common.SolMath.norm(SolMath.java:107)
    at org.destinationsol.common.SolMath.angle(SolMath.java:354)
    at org.destinationsol.game.planet.PlanetObjectsBuilder.buildGroundShip(PlanetObjectsBuilder.java:336)
    at org.destinationsol.game.planet.PlanetObjectsBuilder.buildGroundEnemies(PlanetObjectsBuilder.java:107)
    at org.destinationsol.game.planet.PlanetObjectsBuilder.createShips(PlanetObjectsBuilder.java:88)
    at org.destinationsol.game.planet.PlanetObjectsBuilder.createPlanetObjs(PlanetObjectsBuilder.java:75)
    at org.destinationsol.game.planet.Planet.update(Planet.java:79)
    at org.destinationsol.game.planet.PlanetManager.update(PlanetManager.java:68)
    at org.destinationsol.game.SolGame.lambda$null$2(SolGame.java:385)
    at java.util.ArrayList.forEach(ArrayList.java:1249)
    at org.destinationsol.game.SolGame.lambda$update$3(SolGame.java:384)
    at java.lang.Iterable.forEach(Iterable.java:75)
    at org.destinationsol.game.SolGame.update(SolGame.java:383)
    at org.destinationsol.SolApplication.update(SolApplication.java:251)
    at org.destinationsol.SolApplication.safeUpdate(SolApplication.java:225)
    at org.destinationsol.SolApplication.render(SolApplication.java:189)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Window.update(Lwjgl3Window.java:392)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.loop(Lwjgl3Application.java:137)
    at com.badlogic.gdx.backends.lwjgl3.Lwjgl3Application.<init>(Lwjgl3Application.java:111)
    ... 1 more

If this isn't an obvious bug it may be a call to harden the code somewhere to catch this better and either log more informative details or even skip over something small if it is like a single turret that fails to place (still logging an error, of course

Other stuff:

• [ ] Eventually make a compatibility PR for the warp module and any other modules the GSOC work may break - which I suspect is very few as code in modules so far is really rare
• [ ] Probably just for making an issue to process later, but: are starlanes being placed excessively, to where you can get to many places from many places, rather than have to hop hop hop to get somewhere distant? I got into a way long one to get to an outer system (played with like 6-7 systems). Probably this needs to be balanced by either breaking the starlanes into shorter multi-hop trips or maybe vary the speed based on the length to reach a comparable short-ish duration on any sort of travel.