Scala cli support

[rochala]

First, I want to thank Marwan @Maeeen for adding the initial support for Scala-CLI 🎉

Now, let's talk about this PR.
It contains few major improvements and refactors. They had to be done sooner or later, so I took the opportunity to address multiple issue at once.

1. We've dropped play-json in favor of circe. The reason is, Scastie had a technical debt and long awaiting migration of the database, as many codecs were adjusted to support all snippets. Now we have only derived codecs, which will simplify the development in a major way. If you're wondering why I also migrated to circe, it has better support for http4s.

2. The packages are renamed to match other Scalacenter repositories. Proper kudos was added in readme section.

3. The database migration script is included in this PR, which will handle all the above. It had to happen anyway, as we now have abstraction over snippet, whether it is Sbt one or Scala-CLI one.

Now lets move to the next part.
This PR doesn't address all the problems. After this PR is merged the following PR's will be added:

• reformat of the codebase - I didn't want to clutter this PR even more,
• migration to akka typed actors,

Lastly, let's talk about the chosen solutions in this PR:

• Scala-CLI communicates over BSP. To make running of snippets separate of build tool, we're running them manually. Sadly it is not as fast as we hoped, so in the future, we should take effort to reuse JVM.
• Metals needs to know dependencies and Scala version. There were 2 approaches - 1st, send a task to BSP and then pass it to metals or parse it manually. I chose the latter as metals runner is already under heavy load. That said, when Scala-cli changes the directives, metals can stop working for them. We should be able to handle it in a better fashion, when proper library is extracted from Scala-CLI, which would allow us to manually extract directives at client level.

It will first be deployed on our staging.

[adpi2]

This definition of ScalaTarget is really weird. It mixes 3 notions: the build tool (sbt or Scala CLI), the language version (Scala 2, Scala 3 and the Typelevel Scala) and the platform (JVM, Native or JS).

I propose to redefine it like that:

enum ScalaTarget:
  case ScalaCli
  case Sbt(scalaVersion: ScalaVersion, platform: Platform)

enum ScalaVersion:
  case Scala2(scalaVersion: String)
  case Scala3(scalaVersion: String)
  case Typelevel(scalaVersion: String)

enum Platform:
  case Jvm
  case ScalaJs(scalaJsVersion: String)
  case ScalaNative(scalaNativeVersion: String)

[adpi2]

Same here, this does not make sense to me. But maybe you need to keep it for compatibility.