Fix zipball/tarball name ignoring the name and version properties

[commi]

Since c8f54bf the maven zip/tar name comes from build.finalName instead of the packager's name and version.

So name has no effect on the archive name. With two package executions in one build, both write the same file. On Linux the second one overwrites the first. On Windows the rename fails and the archive keeps the name ${build.finalName}.zip:

before:  my-app-1.0.0-windows.zip   (first execution)
         my-app-1.0.0.zip           (second execution, contains my-tool)

after:   my-app-1.0.0-windows.zip
         my-tool-1.0.0-windows.zip

The README documents ${name}-${version}-${platform}.zip, and the gradle plugin still creates that name. This PR updates the maven plugin so it behaves the same way.

The rename is still there, so the read-only finalName warning from c8f54bf does not come back. It now replaces an existing file, because File.renameTo does not do that on Windows. Otherwise a rebuild without clean keeps the old archive.

zipballName and tarballName still work as before. For projects where name is not the artifactId, the default file name changes.

[fvarrui]

Thanks a lot for the fix and the clear explanation! 🙏

devel has since moved to the new io.github.javapackager packages (groupId, packages and Gradle plugin id change in 2.0.0), so this branch no longer applies as is. I cherry-picked your commit onto devel, keeping you as the author: 656bd94. Git followed the package rename, so the change is exactly yours.

I also added it to the smoke tests: the sample app now creates the zipball and tarball on GNU/Linux, Windows and macOS, with both Maven and Gradle, and CI checks they're named ${name}-${version}-${platform}.zip / .tar.gz (168e68c).

It's in 2.0.0-SNAPSHOT and will ship in 2.0.0, listed as a change in the release notes since the default file name changes when name differs from the artifactId. Closing this PR, as GitHub can't mark the cherry-picked commit as merged.