Fixes#7387
* Fix VM argument passing by .sbtopts file and JAVA_TOOL_OPTIONS environmental variable, improve launcher script integration test setup
* Fix sbt process not exiting in launcher test for --sbt-version
* Fix JAVA_TOOL_OPTIONS in launcher for linux/mac
Fixes https://github.com/sbt/sbt/issues/7118
Problem
-------
sbtn 1.8.1 was built using ubuntu-latest, which meant picking up newer
glibc.
Solution
--------
This downgraded the ubuntu machine to build sbtn.
Fixes#6530
Ref #6101
Problem
-------
Although having sbt server up by default is beneficial to well-tested
platforms like macOS, on less tested setups various native and/or
native-adjacent techniques we use could end up causing instability.
Solution
--------
This adds `--no-server` as a quick way of telling sbt not to start up
the sbt server or create virtual terminal.
In order to start the sbt server we must use the sbt script because
it is the only way to load the .sbtopts and the .jvmopts file properly.
To do so the sbt script can pass a -Dsbt.script prop to the java server.
It is used in the NetworkClient to start the server, and it is replicated
in the BuildServerConnection file (.bsp/sbt.json).
The problem was that -client was different from --client, which
makes for a confusing user experience. So, this change makes
them the same and re-names -client to --java-client. The value
of this is that hopefully -client and --client being the same
feels more logical to users.
JVM powered applications may be given an alternate home by means of the
`user.home` system property, which is handy for managing caches in CI
(the property may be set by different means, including environment
variables such as `JAVA_TOOL_OPTIONS` or `_JAVA_OPTIONS`).
Alas, this doesn't fully work when the `sbt` script downloads the
launcher jar to `$HOME`.
The present change consists in retrieving the value of this property by
means of a `findProperty` function extracted from the existing
`getPreloaded` one (adapted accordingly).
No java process get spawned here.