**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**
sbt 1.10.0 added support for ++ command with external reference,
but broke ++ takes an aggregate command with slash.
**Solution**
This fixes the parser
**Problem**
Currently scripted does version checking to block sbt 2.x plugins
to be cross published from sbt 1.x.
**Solution**
Remove the sbt version matching.
The BSP server didn't reset old diagnostic messages sent to BSP clients under
certain circumstances. This commit mitigates this edge case and ensures that
diagnostics for files that previously had compilation problems are properly
reset when fresh diagnostics messages are sent.
The culprit was a mismatch of map keys: Files with problems were sometimes recorded
under an absolute path, but later attempted to be retrieved by virtual path.
This follows on from #7470, to include all sources, not just managed and
unmanaged, in the source jar, along with all resources (previously only
unmanaged resources were included).
This means that if, for whatever crazy reason, someone does modify the
`sources` task to include additional sources or filter out sources, rather than
using the managed or unmanaged source mechanisms, their changes will still be
reflected in the source jar.