Delete unnecessary namespace parameterization.
Don't use racket/sandbox. Do support GUI programs.

In this commit, we always require racket/gui/base, even for non-GUI user
programs. Doing so is annoying on a GUI OS, and AFAIK a fail on headless
Unix like a Linux VPS. Therefore loading r/g/b on-demand remains to be
done in a future commit.

Meanwhile, this is the first commit where running GUI programs works
properly. The key is to run read-eval-print-loop from the thread
associated with the eventspace. That way,
current-get-interaction-input-port works as-designed, providing an input
port that will continue to pump GUI events while waiting to read.
Interim commit with conditional text/gui.

The mechanics to work whether racket/gui/base is required or not.

But not yet the mechanism to load r/g/b just once on-demand in the main
custodian, and reuse it in additional runs (to avoid the "can't
instantiate r/g/b twice in the same process" error message and possible
segfault).
Checkpoint using imports-gui?

This works, but:

1. imports-gui? is slow-ish, and uses a cache that can get stale.

2. No guard for (require racket/gui/base) at the REPL prompt.
Checkpoint.

- Catch require r/g/b at REPL prompt. But just to error, for now.

- Better comments.
Checkpoint.

Use `raise` to escape REPL thread. In the handler (still in the REPL
thread), do `channel-put` to main thread then exit REPL thread.

Change our module-name-resolver to use this when it catches a require
r/g/b at the REPL prompt. Instead of an error, now it can do the
require! However it needs to restart the REPL for that module.

Hopefully the next commit will be using that same mechanism generally --
to catch require r/g/b when loading a module, requiring r/g/b in the
main thread/custodian/namespace, then restarting the module load -- as a
replacement for the imports-gui? approach.
Checkpoint.

I think this might be it (fingers crossed)!

Handling require r/g/b both in source files and at the REPL prmopt.
Comments, cleanup.
rm imports-gui.rkt
Clean requires, commments.
Split among files.
More file refactoring.
Handle exn:fail

- Handle exn:fail of a module load by restarting with a "blank"
  racket/base REPL.

- Handle exn:fail inside read-eval-print-loop by just calling
  read-eval-print-loop again. Note: I'm a little confused because
  read-eval-print-loop source seems to set a continuation prompt that
  should catch this already. But no, I seem to need the with-handlers
  to catch it.
A few tweaks.
raise & with-handlers => channel-put & break-thread

Don't need to use raise and with-handlers. Instead, sufficient to
channel-put the message. Just also break (or suspend or kill the
thread) so that it doesn't run a bit longer.

Also: lambda -> λ
Don't need msg struct.
Various changes:

- Rename put/break to put/stop. Don't need to use break-thread. Just
  block forever.

- Use put/stop in exn:fail? handler for module loads. Lets us localize
  the with-handler form to just the dynamic-require.

- Use our custom error handler for module loads, too.

- More better comments.
Don't need quotes around file name.
Add/improve some comments.
Merge branch 'no-sandbox'. Support GUI. Closes #26.