feat: use Semver compatibility for dependency info

[keturn]

Version 7 introduced the use of the Semver library (#80) for some functions of version handling. It changed the behavior of getNextVersion methods (as mentioned in its PR), and that left DependencyInfo returning an unsatisfiable version range when a module's minVersion targets a snapshot. (#100)

gestalt/gestalt-module/src/main/java/org/terasology/gestalt/module/dependencyresolution/DependencyInfo.java

Lines 84 to 89 in a51ba07

	public Version getMaxVersion() {
	if (maxVersion == null) {
	if (minVersion.getMajor() == 0) {
	return minVersion.getNextMinorVersion();
	}
	return minVersion.getNextMajorVersion();

Rather than try to re-implement the semantics of satisfying semantic versioning in the DependencyInfo and VersionRange classes, I propose using more of the Semver library's methods for this.

This PR is a step in that direction. It keeps the VersionRange class intact to preserve compatibility, but if a DependencyInfo was defined with only a minimal version, instead of building a gestalt.VersionRange for it, we compile a Semver expression that will determine what matches.

Dependencies: #98. If that is not merged yet, you can review using this diff: v7/test/java11...v7/feat/semverComparison

Questions for Review

• Is the caret expression the right one?
• Is it worth keeping the existing VersionRange class at all, or should we convert entirely?
  • If we convert, be mindful of VersionRangeTest. lowerSnapshotInRange and higherSnapshotOutOfRange are the ones that are easy to miss.
  • I only found one place in Terasology that directly uses VersionRange, and it's easy to update.
• Instead of building an expression out of minVersion, should we allow module metadata to define its own expression?
  • We would need to use the Maven-style expressions in that case in order for compile-time dependency resolution to still work.

[keturn]

TODO: error handling
or maybe using a documented exception here, and error handling in DependencyInfo?

[keturn]

gestalt snapshot dependencies

[skaldarnar]

I'd love to have a uniform code formatter...

[keturn]

what prompted that thought on this line in particular?

[skaldarnar]

hm, probably the length of that line 🤔

[skaldarnar]

I leave the two open questions for later. I do believe that following any common way to define versions would be a reasonable choice (be it similar to npm's advanced range syntax or resembling gradle's version declarations).