Factor out useful libraries from standard library

[jurgenvinju]

Is your feature request related to a problem? Please describe.

Only big bang releases of the Rascal project can make new features inside the standard library available to our users.

One example was origin tracking for JSON, XML and HTML parsers. Another is evolved support for Java language levels in the JDT.

This is unsatisfactory since releasing rascal implies releasing the VScode extension and the Eclipse plugin, which takes a lot of work and manual testing. Independently tested and loosely coupled features like an XML parser should not have to wait for that.

Also, the current rascal.jar is 100Mb largely due to the transitive dependencies of standard library features that most people do not use at all.

Describe the solution you'd like

Factor out libraries into separately released and deployed packages that can evolve on their own:

• [ ] rascal-java - wraps all support by JDT and ASM library for M3 creation
• [ ] rascal-xml - wraps XML reading and writing and data-binding (type-checking), based on jsoup
• [ ] rascal-json - wraps JSON reading and writing and data-binding
• [ ] rascal-csv - wraps the CSV parser
• [ ] rascal-sdf2 - wraps the SDF2 support for Rascal
• [ ] rascal-yaml - wraps the yaml parser
• [ ] rascal-rsf -wraps support for the rigi standard format
• [ ] rascal-sexp - wraps support for S expressions
• [ ] lang/smtlib2 - wraps support for smt-lib2
• [ ] rascal-jdbc - wraps support for extracting data from JDBC data-sources

We would not factor out the following libraries because they are close to the core of Rascal:

• [x] lang/html - is used for Content creation and serving
• [x] lang/diff - important output format for textual differences
• [x] lang/manifest - important for bootstrapping Rascal
• [x] lang/box - important for generating pretty printers, tightly coupled with Java version of box2text

Questions; what to do with these?

• [ ] lang/dimacs
• [ ] lang/aut
• [ ] lang/aterm
• [ ] lang/javascript - move to js-air?
• [ ] lang/pico - move to demo/lang/pico?

In any case, we can start cloning these functionalities in separate components before we throw them out of the standard library, one-by-one.

Describe alternatives you've considered

• keeping everything is one big standard library; it's easier to get an overview, but harder to maintain

[jurgenvinju]

Some of these new components should go to usethesource immediately (rascal-java, rascal-xml, rascal-json), while for others it would make sense to park them at cwi-swat and release their jars nevertheless on releases.usethesource.io.

[jurgenvinju]

it should also be the case that all these libraries en up on the rascal-mpl.org site as documented packages. This way they remain discoverable by users without additional features of the IDEs or the terminal.

e.g. https://www.rascal-mpl.org/docs/Packages/clair/