Using test files from the released jar is brittle and can stop a bootstrap

[jurgenvinju]

Describe the bug

In many compiler tests we compile modules from |std:///| to see how the compiler is doing on the standard library.

1. This is still a good idea, but currently we are reading those sources from jar files which are already released and immutable. They are guaranteed to come from <bootstrapRascalVersion>0.41.0-RC34</bootstrapRascalVersion> in the pom.xml because that is what |std:///| resolves to.
2. If rascal evolves and the object code under test needs adaptation, there is currently no way of doing that.
3. Propose to change |std:///| to |project://rascal/src/org/rascalmpl/library|
4. We can also make an alias for that or at least a global variable to share this location among the tests.

[jurgenvinju]

This is not urgent, but in case we run into this issue during a simple bootstrap where rascal features change, then we would suddenly have this extra worksload of changing the source paths for all the tests.

[DavyLandman]

That is why in #2217 I said: let's keep these non required for now.

The release does not currently depend on the compiler test succeeding.

[jurgenvinju]

There was a possibility of the tests writing .tpl files in target/classes and thus creating .tpl files with the wrong source locs, which at the real compile would not be overwritten due to timestamp analysis. Luckily this is not the case: I've check all pathconfigs and they are writing elsewhere.

There are tests that download projects like drambiguity and salix jars, and compile from those "sources". I think that has the same issue as the above issue with compiling from |std:///|. It would be better to shallow clone those projects source (tagged with a specific version) from github and call getProjectPathConfig(cloneLoc). That way the pathConfig does not need hard-wiring anymore, and we can also test projects that have binary Java dependencies (like clair and flybytes).