Some project confgurations lead to internal crashes of the type-checker with respect no unfound modules in `std:///`

[jurgenvinju]

Describe the bug

|std:///util/Reflective.rsc|(6610,2,<168,84>,<168,86>): |std:///util/Reflective.rsc|:168,84: "No module name found for |std:///Exception.rsc|(0,3651,\<1,0\>,\<122,3\>);\nsrcs=[|file:///Users/jurgenv/git/drambiguity/src|];\nlibs=[|lib://rascal|,|target://salix-core|,|target://salix-contrib|]"
    at getModuleName(|std:///util/Reflective.rsc|(5261,1354,<134,0>,<169,1>))
    at getModuleName(|lib://rascal-core/lang/rascalcore/check/Import.rsc|(3179,64,<87,11>,<87,75>))
    at complete(|lib://rascal-core/lang/rascalcore/check/Import.rsc|(5757,126,<130,18>,<130,144>))
    at getImportAndExtendGraph(|lib://rascal-core/lang/rascalcore/check/Import.rsc|(6022,154,<135,11>,<135,165>))
    at rascalTModelForLocs(|lib://rascal-core/lang/rascalcore/check/Checker.rsc|(9845,7581,<209,8>,<362,5>))
    at check(|lib://rascal-core/lang/rascalcore/check/Checker.rsc|(21389,97,<464,38>,<464,135>))
    at $shell$(|main://$shell$|)

Here we see that |std:///| is not even on the source path. And so getModuleName can't find the module for it. The |std:///| prefix is used by the path rewriter just before the rascal standard library is deployed.

• the type checker should not crash on this, but it should report an error and not generate a whole bunch of downstream unresolved names and types
• projects that have |lib://rascal| on the libs path and not |std:///| need some kind of fix, because this is now unworkable.