fix(plugin): fix package versions on Windows and Mac to not suffixes which break version rules on those platforms

[sproctor]

jpackage rejects SemVer pre-release/build metadata (e.g. "2.3.5-beta.7" fails with "invalid component [5-beta.7]"), but it is the only backend that builds the app-image (RawAppImage); all installer formats route through electron-builder, which accepts full SemVer.

Add a per-OS jpackageVersion (windows/macOS/linux) used only for the jpackage app-image, falling back to packageVersion when unset. The value is passed to jpackage as-is. electron-builder formats continue to use packageVersion with the SemVer suffix intact.

[kdroidFilter]

Thanks for digging into this - the jpackage vs electron-builder version mismatch is a real problem. One concern about the approach, though.

As it stands the fallback chain is jpackageVersion ? packageVersion ? project.version ? "1.0.0". That means the PR doesn't actually fix the failure out of the box ? it adds an opt-in knob. If someone sets packageVersion = "2.3.5-beta.7" and isn't aware they also need to set jpackageVersion,
jpackage still receives the SemVer suffix and fails exactly as before. So the user has to (1) know the problem exists, (2) discover the new property, and (3) set it manually per OS.

Since jpackage only wants a numeric MAJOR.MINOR.PATCH core and the SemVer suffix always starts at - (pre-release) or + (build metadata), we could just strip it automatically for the jpackage app-image and keep the full version for electron-builder:

  // jpackage rejects SemVer pre-release/build metadata; keep only the MAJOR.MINOR.PATCH core.
  private fun String.toJpackageVersion(): String =
      substringBefore('-').substringBefore('+')

  packageTask.packageVersion.set(
      packageVersionFor(packageTask.targetFormat).map { it.toJpackageVersion() }
  )

That fixes 2.3.5-beta.7 for everyone with zero config and no new DSL surface, while electron-builder keeps the SemVer intact via packageVersionFor.

[sproctor]

The msi and nsis also need a package format in the same form. I just followed the path taken there. If we're doing that, I think the same thing should be applied to all formats that are required to be in MAJOR.MINOR.PATCH form.

[sproctor]

Linux packaging works without this change. I believe this is correct, but it's possible that some formats accept other version numbers. I also set the fallback when a target format does not specify a version to strip the suffix on non-linux platforms. I think for the majority of cases, things should just work. If I got something wrong, we can adjust later and it's possible to work around the issue by specifying a version for the package. Perhaps this behavior should be documented as it may be a bit surprising. It shouldn't change any existing usages as currently things fail to build when using pre-release suffixes on windows and mac if you don't specify a trimmed version on those platforms. The github publisher uses the generic packageVersion and the s3 publisher uses the os-specific packageVersion.

[kdroidFilter]

Thank you very much for your contribution, I'll look at it tonight.