Update windows packaging process

[devinbileck]

The 64bitBuild.bat script has been renamed to package.bat and has
been updated so that it is capable of performing the complete packaging
process without having to rely on the jar first being built and prepped
from the MacOS scripts. However, it does support having the jar
previously built and prepped and will look for a prepped jar in the
desktop/package folder. If not found, it will build and prep it
prior to packaging the executable.

Additionally, some unnecessary options that were being passed to
javapackager.exe have been eliminated such as BappVersion and Bruntime.
AppVersion is now being passed via environment variables and the
Bruntime option is valid only when the -native option is set to jnlp.

The Bisq.iss file was changed so it no longer needs to be updated with
AppVersion every time as it is being passed from package.bat via
environment variables. Also, AppCopyrightYear does not need to be
updated as it is determined automatically. A few other options were
added or tweaked as well.

Finally, a release.bat script has been added that will perform the
release process of copying necessary files to a versioned release folder
and generating/verifying signatures. Linux and MacOS packaged installers
should be copied to their appropriate package folders prior to
executing this script if they are to be included in this release
process, otherwise only the Windows files will be included.

The MacOS and Linux packaging scripts should be reviewed and updated
accordingly.

[devinbileck]

I will review and update the Linux packaging scripts next.

[devinbileck]

Note, signing the Windows installer (#1952) is still on my TODO list.

[ManfredKarrer]

@ripcurlx Can you review that PR? I am on holiday untill January.

[ripcurlx]

@devinbileck Sorry for my late review. I was also off most of the time and had a cold on top.
Similar to my remarks here, could you please update

bisq/desktop/package/macosx/create_app.sh

Line 53 in db439ce

cp $EXE_JAR "$win64/Bisq.jar"

as well, so it works within the current build process?

[ripcurlx]

Requested changes merged in #2190

[ripcurlx]

@devinbileck Could you please check if my merge in 3d2817e is correct?

[devinbileck]

@ripcurlx Sure, I will review and test your changes.

[devinbileck]

@ripcurlx The merge looks fine. However, a few comments to other commits:

1. The iss file requires the BOM since it contains unicode messages. Otherwise they will not be displayed properly within the installer for those languages. See https://stackoverflow.com/a/49923030/8871018. Not sure why you are encountering issues? (worked for me with Windows 10)
2. My intention with overriding JAVA_HOME was to simplify the process, rather than the user having to set JAVA_HOME before to OracleJDK, and then change it back afterwards to OpenJDK (its a pity packagemanager is not available in OpenJDK). I agree hard coding the path in the script makes it inflexible in case the user has it installed elsewhere, and they may need to edit it. But, I was considering investigating installing OracleJDK as part of the install_java script and we can have a standardized path (again, a pity that archived Java versions require a user account to download the JDK). I suppose an alternative solution is to use a different variable name within the script and check if the path exists first, else use JAVA_HOME environment variable.

[ripcurlx]

@devinbileck

1. I just removed the BOM as Windows complained during the build that it doesn't like this character in the beginning of the file. You don't see this error when running the script?
2. This was the reason why I removed it as I had a different installation directory on Linux. I removed it from Windows just because of consistency in that case. But yes, we could do some workaround with checking for the javapackager.

[devinbileck]

1. No, worked fine for me. I will give it a try again.
2. I will see what I can do.

[devinbileck]

1. @ripcurlx What is the error that you encounter?

As a result of it now missing the BOM, I just tried the v0.9.3 release installer on Windows 7 French and the custom messages are not displayed properly.

Launch the installer with the application running:

Comment text within the control panel:

Note, this issue will only affect the custom messages contained within the Bisq.iss file, not the general translations within the installer.

Once I added the BOM, the translations above were shown properly.