The DataSource is now part of the Radish.

Radish takes the dbh, the formatter, whether to sort the columns and so on.
It can take a new query or it can re-issue the previous one. It will be
able to toggle paging, change the formatter, output to files and whatever.

There is a RadishFeeder, which takes a Radish object. You can then feed it
interspersed SQL queries and configuration commands. The
configuration/internal commands change the state or configuration of the
Radish and the queries and passed to it. It will takes commands read from a
file and/or from stdin. The shell will also feed commands to it.

The feed that the Radish gets back might and might not have rows. If it
does (and is fetchable) then it will have data to display. If it does not
then it will just display a count of the rows affected.
Feeds can contain partial SQL commands. If they do, the partial commands
are collected until they are complete and are only issued when they are.
Command line parameters, hooray.

To set the output formatter, an input file for commands, an output file for
results (not yet implemented) and whether to echo commands or not.
There was also a pager option but a pager does not make a lot of sense for
a strictly cli program so that is being dropped from here and moved to
just be a shell thing. Although it just occurs that it will be settable by
command line commands, if not switches.

Since the LineFeeder was introduced (which was the RadishFeeder when it
was introduced), the Radish object can not take configuration commands so it
only accepts queries so the methods are query() and requery(), not
process_command() and reprocess_commands(). Nothing should have been called
by those names anyway.

The LineFeeder has a reference to a Radish object and it gets fed lines of
text. The text can be commands which configure the Radish object or they
can be SQL commands and queries to send to the database via the Radish.
If a line starts with a dot, it is an internal command, otherwise it is an
SQL query or part of one. Since queries can span multiple lines, queries
are collected until a command terminator (a semi-colon) is found.
Similarly, if a line contains multiple complete queries, they are all
executed in turn.
An interesting side effect of this design is that an internal command can
come in the middle of an SQL query and that is just fine. That is what
makes the .stop and .go commands possible.

Speaking of the shell, I have to say how much more I like this design.
Start with just command line commands and make sure the output works. Add
different formatters. Let command line switches select them. Add a line
feeder. Have the line feeder work taking commands from stdin, then have the
commands read from file. That is most of the shell done before you write a
line of the shell. With everything else taken care of, the shell involves
little more than writing an input loop and getting readline involved. Since
the linefeeder knows (and can tell you) whether a query is complete, you
can change the prompt to match. Since the linefeeder tells you which
commands it completed, you can easily store them in the history.
Start with the Radish. Then have LineFeeder (which takes a reference to the
Radish) and just feed it lines while forgetting about the Radish yourself.
Then have a shell that has a linefeeder that feeder a radish. Just start
the shell running and you don't have to worry about the linefeeder or the
radish that it feeds.