Re-isolate PPrint + REPL extra libs

[bishabosha]

Need a mechanism to include PPrint classpath within the REPL without exposing it to the user,

current status quo for 3.8 is that the repl launches with pprint/fansi/sourcecode directly visible to the user

[bishabosha]

@hamzaremmal even if you include the vanilla jars from maven central on a hidden classpath then perhaps it would conflict as soon as a user re-includes it via deps or dynamic dep resolution inside a repl session - so if isolation is not achieved by shading package then perhaps a mechanism to "swap" classpath entries and/or make them visible is needed

[lihaoyi]

Seems like having the REPL compile/runtime classpath be fully isolated from the REPL implementation jars is the solution here, but it should not be isolated from the enclosing classpath because we may want to embed the REPL in a larger program and expose program values to the REPL.

The solution is to have the REPL compile/runtime classpath be shared with the enclosing program, but have the REPL's implementation jars be loaded into an isolated classloader so they are not visible and cannot conflict

[SethTisue]

at core meeting today the consensus was to shade as an acceptable-for-now solution, and try for the better solution (proper isolation via classloaders) later