chore(GameIdentifier): remove engineVersion; rename String version to displayVersion

[keturn]

See discussion.

Companion to #654. Split in hopes of more reviewable changes.

Contributes to #651.

Largely reverts e1e530f (#647). Reviewers may want to compare this to the state of things before #647: 8d928d37a1c59bfb375899fb115c7c4abd836b13...fix/removeEngineVersion#diff-eb9f4ead54

I think the GameManager and RepositoryAdapters are what want the closest scrutiny there.

[keturn]

JenkinsRepositoryAdapter is not quite back to its pre-#647 behavior: 8d928d3...fix/removeEngineVersion#diff-0aa9f2a209932ac1aa89399ead549d10d3cea93f42394eafb59542b2f409ed93L99-R99

TerasologyLauncher/src/main/java/org/terasology/launcher/repositories/JenkinsRepositoryAdapter.java

Lines 96 to 100 in 801d347

	private Optional<GameIdentifier> computeIdentifierFrom(Jenkins.Build jenkinsBuildInfo) {
	return Optional.ofNullable(client.getArtifactUrl(jenkinsBuildInfo, "versionInfo.properties"))
	.map(client::requestProperties)
	.flatMap(versionInfo -> GameIdentifier.fromVersionInfo(versionInfo, buildProfile, profile));
	}

ignores jenkinsBuildInfo.number and is using the versionInfo.properties buildNumber instead.

@skaldarnar What do we want here, in the interim before we get distribution versioning?

• go back to using the build number reported by the Repository
• concatenate both build numbers (engine+distribution)
• use engine build number (the current state of this PR)

[skaldarnar]

What do we want here, in the interim before we get distribution versioning?

Hm, let me try to list the pros and cons that come to my mind here:

use engine build number (the current state of this PR)
❌ I think only using the engine build number is not a good choice. On the one hand, we have this potential one-to-many mapping, and many bugfixes actually happen in module land these days, not necessarily in the engine. In other words, I do think the distribution build number is the more important info for differentiating Omega builds.

go back to using the build number reported by the Repository
✔️ ❔ According to my statement above, I think the distribution build number is more important for identifying the "game release". However, the fact that we depend on the Repository to determine this number is not good - we should be able to identify such a release regardless of whether we get it via Jenkins, Github, or whatever.

As the launcher controls how games are installed (and just dropping games manually in the install dir is neither recommended nor in any way supported) we could live with getting the build number from the Repository and persisting it with an installation of the game (to be able to match it back).

concatenate both build numbers (engine+distribution)
✔️ ❔ I think this would be possible, as we have <engineVersion>+<engineBuildNumber> in the version info file, which makes up the GameIdentifier#engineVersion. In lack of proper distribution versioning we then need to assume that the base version for engine and distribution are the same, but for GameIdentifier#version we'd use <engineVersion>+<jenkinsBuildInfo.number>...

---

I think the situation here may get better when we also change how GameIdentifier looks like...

[keturn]

I've put it back to the pre-#647 method of using the distribution Jenkins.Build.number.