Bundle scala cli in scala command

[bishabosha]

fixes #20098

Proposed changes to zip/targz archive:

• in the /bin directory store an extra launcher for Scala CLI (either JAR, or native per platform).
• /bin/scala[.bat] is modified to invoke Scala CLI stored in /bin
• new /maven2 directory, which stores all the Jars and POM files necessary (in maven repo style) for scala-cli to invoke scala compiler offline (using the -r launcher option).
• CHOICE: either replace jar files in /lib by aliases to the corresponding jar in /maven2, OR delete /lib and update references from scripts.
• add platform specific suffixes to artefacts:
  • e.g. scala-3.5.0-x86_64-pc-linux.tar.gz (for the artefact that bundles the x64 linux launcher)

[skip ci]

[bishabosha]

~It appears that on windows a critical class is loaded on boot scala.build.internal.JniGetWinDirs which is compiled by JDK 16, so fails when loading from Java 8. But on Mac OS the jar launcher works fine on java 8 - could it be possible that just this one dependency has a misconfigured build?~

Edit: We can not guarantee that the Jar-based launcher works on JDK 17, so this must be do-not-merge until we implement the native launchers

[He-Pin]

A question is if a new scala-cli is released, will scala update it automatically, like cs update scala-cli?

[bishabosha]

A question is if a new scala-cli is released, will scala update it automatically, like cs update scala-cli?

The way it is currently implemented, the idea would be that each scala version is tied to a specific Scala CLI launcher. and Each scala release would come with whatever is the latest Scala CLI version at that moment

[He-Pin]

1. When do republishing , is there some kind of Sha or md5 checking ?
2. Does Windows platform been well tested?

[hamzaremmal]

• [ ] README.md needs to be updated too

[bishabosha]

@hamzaremmal this is everything that was agreed in the plan, except for deciding what to do about the lib directory - and maybe caching the task to populate the local maven2 repo with coursier - also that relies upon cleaning the repo but it seems ci does that anyway (multiple times)

We would also need to update the ci.yml to publish artefacts for each launcher - and the sdkman publishing, but perhaps that can be another PR?

[hamzaremmal]

We would also need to update the ci.yml to publish artefacts for each launcher - and the sdkman publishing, but perhaps that can be another PR?

Yes, it should be in another PR with the changes to the launchers.yml workflow too. I will take care of it.

[bishabosha]

oh right and we should squash when merging this one I think

[hamzaremmal]

oh right and we should squash when merging this one I think

Definitely

[bishabosha]

I have manually squashed the commits where it makes sense

[hamzaremmal]

Do we still care about testing the JVM launcher on Windows?

(Not sure why I can't reply directly to your comment) We can't run JVM launchers on Windows due to the restriction on the Java version. We will keep releasing the JVM launcher anyways for other uses so it is good to test them too.