Make the repl printing function configurable #3177

The context of this is that I'm starting to get somewhere with my Show replacement experiment (see https://github.com/hdgarrood/purescript-debugged/), and I've been testing it out in the repl. I've had to make a very hacky workaround to do this, which is to define a module called PSCI.Support which exports a function eval, because the repl is hardcoded to expect to find a function called eval within a module called PSCI.Support; what this currently means is that if you try to install purescript-debugged together with anything that depends on purescript-psci-support (which is most things), you'll get an error due to the module name clash. That is, it doesn't appear to be possible to override the repl printing function without making your code incompatible with any other library which depends on psci-support.

Of course you can use your own printing function already just by writing it out each time, i.e. > myPrint $ whatever inside the repl instead of just > whatever, but I think not having to do that can make quite a big difference in terms of how nice it is to use.

See also what GHCi does for reference.

The interface I'm proposing is:

• the repl exposes a configuration option interactive-print which can be left blank (in which case the repl continues to use PSCI.Support.eval), or set to a string like Data.MyPrint.print.
• if specified, this configuration option should be a fully-qualified identifier, which references a function whose type should be something like forall a. C a => a -> T.
• the repl then applies this function to any expression entered at the repl, obtaining a value of type T.
• the runtime representation of the type T should be the same as that of Eff, namely a nullary function which, when called, does something (possibly involving side-effects). In this case, the side-effects of the function would usually be printing a representation of the argument to the console. The repl finally calls the result of the previous step to actually perform the side-effects.

One thing I like about this proposal is that it reduces the repl's dependency on prelude and makes more space for alternative preludes; currently you kind of have to have Show instances for most data types in your project for the repl to be useful, even if you're not using the standard prelude in any other way. We generally aim to have the compiler tied to the standard prelude as little as possible, and I think this is one of the last remaining instances of overly strongly coupling between the compiler and the standard prelude.