Do not (ab)use blocks for top level trees

Dispatchers are the only place where we pass a dynamically computed
string to the VarGen subsystem.

Allocate all emitter var field strings statically

…dual files

Add java.io.FilterReader

Previously, the `.sjsir` files of the scalalib (and libraryAux)
were bundled inside scalajs-library.jar. With the plan to drop
forward binary compatibility of the upstream scala-library.jar,
this model will not work anymore.

We now publish those `.sjsir` files in their own artifact
`scalajs-scalalib.jar`. It is versioned *both* with the Scala
version number and the Scala.js version number, in a way that will
allow Ivy resolution to pick the right one.

At the POM level, `scalajs-scalalib` depends on `scalajs-javalib`.
`scalajs-library` depends on the other two. However, in terms of
*actual* content dependencies, as is, `scalajs-scalalib` also
depends on `scalajs-library`.

If the former is present on a classpath but not (a recent enough
version of) the latter, linking errors can appear. This should
not be an issue because any real build that depends on
`scalajs-scalalib` will also depend on `scalajs-library`. Moreover,
if a more recent `scalajs-scalalib` is picked up by Ivy resolution
that implicitly depends on a more recent `scalajs-library`, the
library that introduces that dependency would also *explicitly*
depend on the more recent `scalajs-library`, and so the latter
would also be picked up by Ivy resolution.

The sbt plugin explicitly adds a dependency on the
`scalajs-scalalib` with a Scala/Scala.js version combination
that matches `scalaVersion` and `scalaJSVersion`. This way,
if it uses a Scala.js version that was built for Scala 2.13.12
but it itself uses Scala 2.13.15, it will get the back-published
`scalajs-library` built for Scala 2.13.15.

Split the scalalib .sjsir files in a separate artifact scalajs-scalalib.