fix builtin ambiguous classpath for rascal-lsp

[jurgenvinju]

This practically always leads to two rascal-lsp jars on the classpath. This is problematic when developing Java code, or when maintaining the rascal-lsp itself. Say you rename a class, then the old class will always still be on the path. All kinds of tricky things can happen that can be avoided by not including the rascal-lsp jar if it is already there by configuration.

See PathConfig.java:

 // We add rascal-lsp to the PathConfig if it is present on the classpath
        // This version of rascal-lsp is added last, so an explicit rascal-lsp dependency takes precedence
        try {
            var lsp = PathConfig.resolveProjectOnClasspath("rascal-lsp");
            if (mode == RascalConfigMode.INTERPRETER) {
                srcs.append(URIUtil.getChildLocation(JarURIResolver.jarify(lsp), "library"));
            }
            // the interpreter must load the Java parts for calling util::IDEServices and registerLanguage
            addLibraryToLibPath(libs, mode, lsp);
        }
        catch (IOException e) {
            // This is expected when rascal-lsp is not on the classpath
        }

[toinehartman]

I think #2828 solves this.