This PR is a proof-of-concept implementation porting over the Ammonite import $ivy functionality to the Scala REPL, using the Scala-CLI using dep syntax. Once this lands, along with other related PRs (#24127, #23849) we can probably deprecate Ammonite and refer people to the main Scala REPL since it'll have acquired all the important features

Tested manually:

$ JAVA_HOME=~/Library/Caches/Coursier/arc/https/cdn.azul.com/zulu/bin/zulu17.56.15-ca-jdk17.0.14-macosx_aarch64.tar.gz/zulu17.56.15-ca-jdk17.0.14-macosx_aarch64/ bin/scala
The `--offline` option is experimental
Please bear in mind that non-ideal user experience should be expected.
If you encounter any bugs or have feedback to share, make sure to reach out to the maintenance team at https://github.com/VirtusLab/scala-cli
Welcome to Scala 3.8.0-RC1-bin-SNAPSHOT-git-17e82e6 (17.0.14, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
 
scala> import scalatags.Text.all._
-- [E006] Not Found Error: -----------------------------------------------------
1 |import scalatags.Text.all._
 | ^^^^^^^^^
 | Not found: scalatags
 |
 | longer explanation available when compiling with `-explain`
1 error found
 
scala> //> using dep "com.lihaoyi::scalatags:0.13.1"
Resolved 1 dependencies (5 JARs)
 
scala> import scalatags.Text.all._
 
scala> div("hello world").render
val res0: String = "<div>hello world</div>"

Both io.get-coursier:interface and org.virtuslab:using_directives are zero-dependency Java libraries, and so can be used directly without worrying about binary compatibility. Both libraries are widely used in the Scala ecosystem (SBT, Mill, ScalaCLI, Bazel, ...) and should be pretty trustworthy and reliable

Not sure if we want to put this into the compiler codebase, but that's where the REPL logic currently lives, and I figure anyone working on the compiler may find it useful as well. e.g. You can pull in third-party libraries when working in the REPL to see how a new language feature interacts with an existing library.

We can move the logic out of the compiler codebase if we want, but as a first pass this integration seems relatively straightforward. The "correct" way of re-organizing this would be to split the dotty.tools.repl into a separate subproject from the rest of compiler so programmatic non-REPL use cases (e.g. build tools) don't need to pull it in, but that would be a larger refactor beyond the scope of this PR