Improve packaging and distribution system

[pditommaso]

Summary

Nextflow application is a packaged as a set of JAR files (Java archives) that are uploaded to Maven central repository with the exception of the launcher app that's stored in http://nextflow.io/releases/

The nextflow "binary" is a mere Bash script that checks if the launcher app is stored locally. If it cannot be found it download it from the http://nextflow.io/releases URL and run it.

Then the launcher app, uses the Capsule package manager to download the main application JARs from Maven along with all required dependencies files.

This system worked quite nicely for many years, however there are some serious open issues:

• The Capsule system has been is not maintained anymore by the original author. Considering the new fast release cadence of the JVM this can because soon a problem (see below)
• Recent Java release has introduced a slightly different version scheme that the Capsule system fail to recognise. This creates problems with some users that need to change Java distribution to use Nextflow. See here and here and here
• The Capsule system breaks when using _JAVA_OPTIONS variable. See here
• The Capsule system fails to download and unpack the deps in some systems because it requires to create file system lock, which not all file system supports. See here
• The new nextflow plugins system makes the capsule system not needed anymore.

Goals

• Remove the dependency on Capsule package system
• Create instead a standalone nextflow distribution for the core runtime. The Nextflow plugin system will continue to download the required plugins separately
• Keep the compatibility with the existing nextflow launcher wrapper

Non-goals

• the support for JReleaser or other Linux package managers such as RPM, Debian, etc. is out of the scope of this issue, however, it's desirable that the overall design to be compatible with the packaging those system, that could be adopted in the future