**Problem**
client-side run apparently won't work for Scala.JS,
so forcing sbtn users to client-side run will break the Scala.JS users.
**Solution**
This reverts the client-side run on sbt 1.x, while retaining the
mechanism for sbt 2.x usages via sbtn.
Now, if `run / connectInput := true` is true, stdout will not display on sbtn.
**Problem**
There are a few places where javaHome or java path is set,
using java.home system property. The problem is that it points to JRE,
not JDK, so it would break on Java compilation etc.
**Solution**
If the path ends with jre, go up one directory.
**Problem**
`run` task blocks the server, but during the run the server is just
waiting for the built program to finish.
**Solution**
This implements client-side run where the server creates a sandbox
environment, and sends the information to the client,
and the client forks a new JVM to perform the run.
**Problem**
When ForkOptions outputStrategy is None, Run code currently
tries to use LoggedOutput, which buffers the output when
connectInput is true, which effectively breaks the experience.
**Solution**
This stops falling back to LoggedOutput when connectInput is true.
**Problem**
The sbtn response handling code is relatively stragightforward,
but it's a bit messy.
**Solution**
This cleans it up a bit, similar to the style used by Unfiltered
back then (not sure how Unfiltered plans are written nowadays) by
expressing each event handling as a partial function, and composing them
together using `orElse`.
**Problem**
We changed the content of Chrome tracing file incorrectly
and renamed tid to tname.
**Solution**
1. This renames tname back to to tid.
2. To retain the fix to avoid Thread#getId, this calls
either the JDK 8 way or the JDK 19 way reflectively.
Add a `allowUnsafeScalaLibUpgrade` setting (default is `false`) to
demote the SIP-51 build failure to a warning.
If the scalaVersion is 2.13.12 but some dependency pulls in
scala-library 2.13.13, the compiler will stay at 2.13.12, but
the dependency classpath will contain scala-library 2.13.13.
This usually works, the compiler can run fine with a newer
scala-library on its dependency classpath.
Macro expansion may fail, if the macro uses some library
class / method that doesn't exist in the old version.
The macro itself is loaded from the dependency classpath
into the class loader running the compiler, where the older
Scala library is on the runtime classpath.
Using the Scala REPL in sbt may also fail in a similar fashion.
**Problem**
BOM support current has perf issues.
**Solution**
This bumps Coursier to 2.1.22.
This also adds a new setting `csrMavenDependencyOverride`,
which will default to false.
**Problem**
1. Currently users are automatically opted into -create-sbt,
somewhat implicitly.
2. When somehow they are not, the check mechanism currently blocks for input.
**Solution**
1. Support a new location for sbtopts file under XSG_CONFIG_HOME/sbt
2. Rename -create-sbt to --allow-empty, and don't opt everyone in
3. Exit 1 instead of blocking for input
Eugene Yokota
mehdi
Dmitrii Naumenko
Josh Soref
Lukas Rytz
Derek Wickern
friendseeker
adpi2