Ordering of `!current_version` not equivalent to `BuildVersion.getVersion()`

[alecgrieser]

Within the YAML test framework, we have a macro for the current code version (!current_version), and we can use it within tests to make test execution conditional on whether the code is locally built or not (so that, say, new features will run through the code path but we won't try and execute the test during mixed-mode testing).

However, there's an issue here due to how our release process currently works. We update the version in gradle.properties (which is ultimately what powers BuildVersion.getVersion()) at the beginning of a release. That means that if the developer has a local copy on main, then the version they build will have the same version as the most recent release but it will be marked as a SNAPSHOT build. Our SemanticVersion class currently treats SNAPSHOT builds as coming before release builds with the same number, so the local build will therefore be marked as coming before the most recent release.

The BuildVersion.getVersion() value is also included in the jar name of a locally built ExternalServer that gets run against the embedded config during the execution of the multi-server YAML tests. That means that to get that server to run against all of the different conditions correctly, we need to have the version of that ExternalServer be consistent with !current_version. The solution enacted in #3188 is to have the ExternalServer return a special "current version" version, which aligns with what the EmbeddedConfig does. Which gets the job done, but it would be nice if !current_version sorted correctly by having it be based on BuildVersion.getVersion(). To do that, we could

1. Change our release process to bump at the end rather than the beginning. The concern before had been that failed builds may mean that we end up missing pushes, which could be bad, especially if there's a bungled publishing. However, we can adjust our release process to publish separately, and then make the process a bit more resilient to failures pushing, which should alleviate most of the concerns there.
2. Change how SemanticVersions treat SNAPSHOT builds. Effectively all of the standards suggest that x.y.z.t-SNAPSHOT should sort before x.y.z.t, but you know, we could flip the comparison.
3. When in non-release mode, have BuildVersion.getVersion() return an incremented version for local consumption. So something like if the version in gradle.properties is x.y.z.0, it could return x.y.z.1-SNAPSHOT. In release mode, we go back to returning just x.y.z.0.