For the details about this PR, please see the blog post https://eed3si9n.com/sbt-remote-cache/.
* Add cache basics
* Refactor Attributed to use StringAttributeMap, which is Map[StringAttributeKey, String]
* Implement disk cache
* Rename Package to Pkg
* Virtualize packageBin
* Use HashedVirtualFileRef for packageBin
* Virtualize compile task
Fixes https://github.com/sbt/sbt/issues/7327
**Problem**
In builds with mixed Scala patch versions (like scalameta),
it's possible for a core subproject to be set to the lastest 2.12.x,
but the compiler plugin component is cross published to 2.12.0 etc.
`++ 2.12.0` in this case does not work since sbt 1.7.x onwards requires
the queried Scala version to be listed in `crossScalaVersions`.
**Solution**
This implements sbt 1.6.x-like fallback mechanism,
but instead of using the queried version (e.g. 2.12.0) it will set
the Scala version to one of listed versions that is binary compatible.
Problem
-------
In sbt 1, platform cross building is implemented using in the user-land
using `%%%` operator, which clevery handles both Scala cross building
and appending platform suffix like sjs1.
However, in general symbolic `%%%` is confusing, and hard to explain.
Solution
--------
In sbt 2, we should subsume the idea of platform cross building,
so `%%` can act as the current `%%%` operator.
This adds a new setting called `platform`, which defaults to
`Platform.jvm` by default.
When a subprojects sets it to `Platform.sjs1`, `ModuleID`s defined using
`%%` operator will inject the platform suffix `_sjs1` **in addition**
to the Scala binary suffix `_2.13` etc.
Note: Explicit JVM dependencies will now require `.platform(Platform.jvm)`.
Fixes https://github.com/sbt/sbt/issues/7117
Problem
-------
sbt no longer works on a Mac with M1 (aarch64) chips because it fails on
ipcsocket library, which we maintain.
This was caused by architecture detection that was added in 1.6.1,
which did not take in account for macOS universal binary.
Solution
--------
Update to ipcsocket 1.6.2.
Launcher 1.4.1 is capable of launching Scala 3 apps.
In other words, launchers prior to 1.4.1 are not capable of
launching Scala 3 apps, including tests for sbt 2.x.
This removes OkHttp dependency.
This also removes an experimental feature to customize HTTP for Ivy called
CustomHttp we added in sbt 1.3.0.
Since LM got switched to Coursier in 1.3.0, I don't think we advertized
CustomHttp.
Ref https://github.com/sbt/sbt/issues/6912
Problem
-------
There's apparently a security issue with OkHttp 3.x,
which I am not really sure how applicable it is to our usage
of OkHttp but it is there.
Solution
--------
Since most of OkHttp-specic usage within LM is for Apache Ivy
downloading, I am going to drop this.
Since `sbt.librarymanagement.Http.http` is a public API,
I am substituting this with Apache HTTP backed implementation.