Remove lib scheme, only allow it in RASCAL.mf file as a reference to a dependency of the project

[DavyLandman]

Is your feature request related to a problem? Please describe.
The lib scheme has given us a lot, both in functionality and subtle bugs. Multiple developers of rascal have had many discussion on this scheme.

The problem is that the are not stable. Where |lib://typepal| depends on is mostly depending on the resolution of the maven project, or more specifically on the classes you've loaded. There have been ideas to add versions to the lib locations: #1824 and #1777. But that makes the writing of the RASCAL.MF very repetitive (as you have to copy the same version as is mentioned in the pom.xml) and would mean we have to break backwards compatibility.

Describe the solution you'd like
In a recent discussion with @jurgenvinju we came up with the following strategy:

• remove lib scheme as a resolver.
• but in RASCAL.MF we allow the lib locations, as a way to say: please look at the maven (and workspace) for this dependency
• the path config calculation rewrites the lib location to either:
  • |maven://<namespace>/<package/<version>| that refers to a jar in the MAVEN_HOME folder
  • a |file:///...| path that refers to a local file/directory
  • a |project:///| path that refers to an open project in the workspace

this means that the path config code calculates there the lib dependency points to, and makes that absolute, so no other code has to redo this calculation. Currently this logic was copied to at least 4 places.

Describe alternatives you've considered
See discussions in #1824 and #1777.

Additional context
This solves a range of bugs:

• typechecker in VS Code never get a lib://typepal leaking in from the JVM that rascal-core is running with. but always the version from the target project
• virtual file system in VS Code will resolve more locations from the REPL correctly
• rascal navigator will not have incorrect locations that aren't resolvable.

[jurgenvinju]

I think that a URI is not the right syntax for a project dependency. So we should allow bare project names in Require-Libraries. And warn of the old lib scheme is used.

[DavyLandman]

ah yes, that would be even better.

[jurgenvinju]

This is continued here at #1916, with an actual proposal.